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SYSTEM 

Assistant Commissioner for Patents 
Alexandria, VA 22313-1450 



DECLARATION UNDER 37 CFR 1,131 

Dear Sir: 

We, Dave McDysan, Howard Lee Thomas, and Lei Yao, declare as follows: 

1. We were employed by MCI, Inc., now an affiliate of Verizon Communications, Inc., 
assignee in interest for the subject matter of the above-referenced patent application, U.S. 
Application Serial Number 09/723,501, when the invention was conceived in this country and 
when the application was subsequently filed on November 28, 2000. In that capacity, we have 
personal knowledge of the facts and circumstances stated herein, except those statements which 
are made upon information and belief as set forth below. 

2. We are joint inventors of the above-referenced patent application (Exhibit N). 
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3. It is our understanding that an Office Action mailed January 13, 2006 for the present 
application rejected claims 2-6, 9, 20-24, 27, 37, and 38 under 35 U.S.C. § 102(e) as anticipated 
by Miles et al. (U.S. 6,665,495) and rejected claims 7-8, 10-18, 25-26, 28-36 as obvious under 35 
U.S.C. § 103(a) based, at least in part, on Miles et al. 

4. We conceived our invention in this country long prior to October 27, 2000 (hereinafter 
the effective date), the effective filing date of U.S. Patent No. 6,665,495 entitled "Non-Blocking, 
Scalable Optical Router Architecture and Method for Routing Optical Traffic" to Miles et al. 

5. Long prior to October 27, 2000, we prepared a description of our invention, a copy of 
which is attached hereto (Exhibit A). Although the dates of inventor signatures, headers, footers, 
and additional descriptive material has been redacted, we attest that the description was prepared 
long prior to the effective date of October 27, 2000. 

6. Prior to October 27, 2000, and through November 28, 2000, we collaborated with 
Attorneys Brian Russell and Paul Roberts at least by telephone and email in their preparation of 
drafts of the above-referenced patent application, to review the drafts and suggest revisions, as 
evidenced at least by Exhibits B - L, in which page headers and footers, internal numbers, 
telephone numbers, email addresses, names of people copied on correspondence, and dates and 
times have been redacted. 
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7. Exhibit E denotes an email message dated August 31, 2000 from Attorney Brian 
Russell to co-inventor Lei Yao explaining that a draft application was almost complete for co- 
in ventor review. 

8. Exhibit D denotes an email message dated September 5, 2000 from co-inventor Lei 
Yao to Attorney Brian Russell acknowledging receipt of the email of Exhibit E. 

9. Exhibit C denotes an email message dated September 5, 2000 from Attorney Brian 
Russell to co-inventor Lei Yao reporting an attached draft application for co-inventor review. 

10. Exhibit B denotes an email message dated October 5, 2000 from co-inventor Lei Yao 
to Attorney Brian Russell reporting attached consolidated co-inventor comments on a draft 
application. 

11. Exhibit F denotes an email message dated October 26, 2000 from Attorney Brian 
Russell to all three co-inventors explaining his progress in revising the draft application. 

12. Exhibit G denotes an email message dated November 6, 2000 from Attorney Brian 
Russell to all three co-inventors reporting an attached revised application for co-inventor review. 

13. Exhibit H denotes an email message dated November 6, 2000 from Attorney Brian 
Russell to all three co-inventors reporting an attached revised application for co-inventor review. 
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14. Exhibit I denotes an email message dated November 8, 2000 from co-inventor Lei 
Yao to Attorney Brian Russell acknowledging receipt of revised applications for co-inventor 
review. 

15. Exhibit J denotes an email message dated November 8, 2000 from Attorney Brian 
Russell to all three co-inventors reporting an attached file related to the above-referenced 
application for co-inventor review. 

14. Exhibit K denotes an email message dated November 21, 2000 from co-inventor Lei 
Yao to Attorney Paul Roberts reporting attached consolidated co-inventor comments for a final 
draft of at least the above-referenced application. 

15. Exhibit L denotes an email message dated November 22, 2000 from Attorney Brian 
Russell to all three co-inventors reporting his incorporation of their comments into a final draft of 
the above-referenced application and requesting current address information for preparation of 
formal documents for all three co-inventors. 

16. The above-referenced application was subsequently filed on November 28, 2000, as 
evidenced by the Updated Filing Receipt (Exhibit M). 

17. Due diligence was exercised from prior to October 27, 2000 to the filing date of 
November 28, 2000 (Exhibits B - M). 
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18. We do not know and do not believe that our invention has been in public prior to our 
application, and we have never abandoned the invention. 



19. All statements made herein are true of our own knowledge and that all statements 
made on information and belief are believed to be true; and further that these statements were 
made with the knowledge that willful false statements, and the like so made, are punishable by 
fine or imprisonment, or both, under Section 1001 of Title 18 of the United States Code, and that 
such willful false statements may jeopardize the validity of the patent. 



Respectfully submitted, 




Dave McDysan 



Howard Lee Thomas 



Date 



Lei Yao 
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3. It is our understanding that an Office Action mailed January 13, 2006 for the present 
application rejected claims 2-6, 9, 20-24, 27, 37, and 38 under 35 U.S.C. § 102(e) as anticipated 
by Miles et al (U.S. 6,665,495) and rejected claims 7-8, 10-18, 25-26, 28-36 as obvious under 35 
U.S.C. § 103(a) based, at least in part, on Miles et al. 

4. We conceived our invention in this country long prior to October 27, 2000 (hereinafter 
the effective date), the effective filing date of U.S. Patent No. 6,665,495 entitled "Non-Blocking, 
Scalable Optical Router Architecture and Method for Routing Optical Traffic" to Miles et al. 

5. Long prior to October 27, 2000, we prepared a description of our invention, a copy of 
which is attached hereto (Exhibit A). Although the dates of inventor signatures, headers, footers, 
and additional descriptive material has been redacted, we attest that the description was prepared 
long prior to the effective date of October 27, 2000. 

6. Prior to October 27, 2000, and through November 28, 2000, we collaborated with 
Attorneys Brian Russell and Paul Roberts at least by telephone and email in their preparation of 
drafts of the above-referenced patent application, to review the drafts and suggest revisions, as 
evidenced at least by Exhibits B - L, in which page headers and footers, internal numbers, 
telephone numbers, email addresses, names of people copied on correspondence, and dates and 
times have been redacted. 
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7. Exhibit E denotes an email message dated August 31, 2000 from Attorney Brian 
Russell to co-inventor Lei Yao explaining that a draft application was almost complete for co- 
inventor review. 

8. Exhibit D denotes an email message dated September 5, 2000 from co-inventor Lei 
Yao to Attorney Brian Russell acknowledging receipt of the email of Exhibit E. 

9. Exhibit C denotes an email message dated September 5, 2000 from Attorney Brian 
Russell to co-inventor Lei Yao reporting an attached draft application for co-inventor review. 

10. Exhibit B denotes an email message dated October 5, 2000 from co-inventor Lei Yao 
to Attorney Brian Russell reporting attached consolidated co-inventor comments on a draft 
application. 

11. Exhibit F denotes an email message dated October 26, 2000 from Attorney Brian 
Russell to all three co-inventors explaining his progress in revising the draft application. 

12. Exhibit G denotes an email message dated November 6, 2000 from Attorney Brian 
Russell to all three co-inventors reporting an attached revised application for co-inventor review. 

13. Exhibit H denotes an email message dated November 6, 2000 from Attorney Brian 
Russell to all three co-inventors reporting an attached revised application for co-inventor review. 
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14. Exhibit I denotes an email message dated November 8, 2000 from co-inventor Lei 
Yao to Attorney Brian Russell acknowledging receipt of revised applications for co-inventor 
review. 

15. Exhibit J denotes an email message dated November 8, 2000 from Attorney Brian 
Russell to all three co-inventors reporting an attached file related to the above-referenced 
application for co-inventor review. 

14. Exhibit K denotes an email message dated November 21, 2000 from co-inventor Lei 
Yao to Attorney Paul Roberts reporting attached consolidated co-inventor comments for a final 
draft of at least the above-referenced application. 

15. Exhibit L denotes an email message dated November 22, 2000 from Attorney Brian 
Russell to all three co-inventors reporting his incorporation of their comments into a final draft of 
the above-referenced application and requesting current address information for preparation of 
formal documents for all three co-inventors. 

16. The above-referenced application was subsequently filed on November 28, 2000, as 
evidenced by the Updated Filing Receipt (Exhibit M). 

17. Due diligence was exercised from prior to October 27, 2000 to the filing date of 
November 28, 2000 (Exhibits B - M). 
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18. We do not know and do not believe that our invention has been in public prior to our 
application, and we have never abandoned the invention. 



19. All statements made herein are true of our own knowledge and that all statements 
made on information and belief are believed to be true; and further that these statements were 
made with the knowledge that willful false statements, and the like so made, are punishable by 
fine or imprisonment, or both, under Section 1001 of Title 18 of the United States Code, and that 
such willful false statements may jeopardize the validity of the patent. 



Respectfully submitted, 



Date 



Dave McDysan 



Date 



Howard Lee Thomas 




Date 




5 



09/723,501 



Patent 



IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



In re Application of: 










David E. MCDYSAN et al. 


Conf. No.: 


7593 


Application No.: 


09/723,501 


Examiner: 


Gold, A. 


Filed: 


November 28, 2000 


Group Art Unit: 


2157 


Customer No.: 


25537 






Attorney Docket No.: 


RIC00043 






Client Docket No.: 


09710-1236 







For: EXTERNAL PROCESSOR FOR A DISTRIBUTED NETWORK ACCESS 
SYSTEM 

Assistant Commissioner for Patents 
Alexandria, VA 22313-1450 



DECLARATION UNDER 37 CFR 1.131 

Dear Sir: 

We, Dave McDysan, Howard Lee Thomas, and Lei Yao, declare as follows: 

1. We were employed by MCI, Inc., now an affiliate of Verizon Communications, Inc., 
assignee in interest for the subject matter of the above-referenced patent application, U.S. 
Application Serial Number 09/723,501, when the invention was conceived in this country and 
when the application was subsequently filed on November 28, 2000. In that capacity, we have 
personal knowledge of the facts and circumstances stated herein, except those statements which 
are made upon information and belief as set forth below. 

2. We are joint inventors of the above-referenced patent application (Exhibit N). 



1 



09/723,501 



Patent 



3. It is our understanding that an Office Action mailed January 13, 2006 for the present 
application rejected claims 2-6, 9, 20-24, 27, 37, and 38 under 35 U.S.C. § 102(e) as anticipated 
by Miles et al. (U.S. 6,665,495) and rejected claims 7-8, 10-18, 25-26, 28-36 as obvious under 35 
U.S.C. § 103(a) based, at least in part, on Miles et al. 

4. We conceived our invention in this country long prior to October 27, 2000 (hereinafter 
the effective date), the effective filing date of U.S. Patent No. 6,665,495 entitled "Non-Blocking, 
Scalable Optical Router Architecture and Method for Routing Optical Traffic" to Miles et al. 

5. Long prior to October 27, 2000, we prepared a description of our invention, a copy of 
which is attached hereto (Exhibit A). Although the dates of inventor signatures, headers, footers, 
and additional descriptive material has been redacted, we attest that the description was prepared 
long prior to the effective date of October 27, 2000. 

6. Prior to October 27, 2000, and through November 28, 2000, we collaborated with 
Attorneys Brian Russell and Paul Roberts at least by telephone and email in their preparation of 
drafts of the above-referenced patent application, to review the drafts and suggest revisions, as 
evidenced at least by Exhibits B - L, in which page headers and footers, internal numbers, 
telephone numbers, email addresses, names of people copied on correspondence, and dates and 
times have been redacted. 
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Russell to co-inventor Lei Yao explaining that a draft application was almost complete for co- 
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14. Exhibit I denotes an email message dated November 8, 2000 from co-inventor Lei 
Yao to Attorney Brian Russell acknowledging receipt of revised applications for co-inventor 
review. 

15. Exhibit J denotes an email message dated November 8, 2000 from Attorney Brian 
Russell to all three co-inventors reporting an attached file related to the above-referenced 
application for co-inventor review. 

14. Exhibit K denotes an email message dated November 21, 2000 from co-inventor Lei 
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15. Exhibit L denotes an email message dated November 22, 2000 from Attorney Brian 
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17. Due diligence was exercised from prior to October 27, 2000 to the filing date of 
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18. We do not know and do not believe that our invention has been in public prior to our 
application, and we have never abandoned the invention. 



19. All statements made herein are true of our own knowledge and that all statements 
made on information and belief are believed to be true; and further that these statements were 
made with the knowledge that willful false statements, and the like so made, are punishable by 
fine or imprisonment, or both, under Section 1001 of Title 18 of the United States Code, and that 
such willful false statements may jeopardize the validity of the patent. 




Respectfully submitted, 



Dave McDysan 



Date 



Howard Lee Thomas 



Date 



Lei Yao 
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Provide a short, descriptive title of the invention: 

Distributed Programmabie Access Device Network Supported by Separate Service Controllers 

^esT^ Undef Wh3t CirCumstances was the inventi °n first conceived (if you have any written evidence of this date, include 
The invention was born out of initiatives within the Company to provide customers with integrated access to ail Company 
servic^sandtoprwide a^^rs capabilities to adjust their services, either in type or quantity. The inventors 

il^^^^^^^^^^BBBBMBBBHPBBMBBBMeveloped this invention while working on various proiects 
directed toward pushing network Intelligence and integrated access to the edge of the network and separating switching and 
routing from control functions throughout the network. 
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Describe the invention using the following format. Use as many pages as necessary. Mark each additional page "MCI 
WorldCom Confidential." 



1 . Discuss the problems which the item is designed to solve. Refer to any prior devices of a similar nature with which you 
may be familiar. 

A. Today's routers implement the routing, forwarding, policy, policing, marking, and admission control functions in a 
monolithic, proprietary manner. A few routers have limited implementation of external policy control. The services 
that a provider can offer are limited by the control software implemented by a particular router/switch vendor. If a 
service provider has routers from multiple vendors in a network, the proprietary services will not inter-operate. 
Consequently, the service provider is not able to purchase router/switches from one vendor and purchase policy- 
based service control from another vendor. Furthermore, a service provider cannot offer its network as a platform 
for a wholesale provider to offer value-added services utilizing the existing base network capabilities. 

B. The implementation of the multiple functions listed above in a monolithic router presents a significant scalability 
challenge for vendors in response to the phenomenal growth of Internet traffic. The current design approach by the 
industry separates the problem into core and access routers. Access routers perform the most complex functions 
and perform operations that simplify the tasks required of core routers. However, the monolithic design of access 
routers presents a limit for scalability of the Internet. Evidence of this fact is that the access router software image 
size is increasing. 

C. Another problem brought on by the rapid growth of Internet traffic is the need to dynamically provision, configure, 
and/or reallocate access capacity to IP-based services. Access capacity is often limited and a major cost 
component of modern networks. Therefore, it is subject to congestion and has a strong need for admission control 
and different levels of quality. Also, access products are not capable of handling a wide variety of traffic types while 
being able to enforce policy controls (provider-initiated or customer-initiated) or dynamic requests for capacity. 

D. Today's routers cannot distinguish between higher layer message types and forward the higher layer messages 
according to service/policy parameters. Today's routers do not use a combination of protocol type, source IP 
address (SA), destination IP address (DA), type of service (TOS) or differentiated service code-point (DSCP), 
source port number (SP) and destination port number (DP) to distinguish different message types. In fact, most 
routers use only the DA to make the forwarding decision. Some newer routers use only DA plus TOS/DSCP. 

E. Today's access routers have a concept of one controller providing all services for all message types. This results 
in a single complex router, which is difficult to add new services or modify existing services. This monolithic design 
limits flexibility and extensibility and increases cost. Evidence of this fact is that the time to market for new 
features and functions are delayed. For example, In today's network, if a service provider's external policy server 
sends COPS messages to an access router, the service provider must ask the vendor to develop a COPS 
interface on the router. 

F. Today's routers have relatively weak security control of their configuration information. For example, a command 
line interface is invoked by a simple userid password exchange in the clear when initiating over a telnet session. 

G. Desktop computing applications provide customers with the means to utilize many different services while each 
service requires different (quality of) service requirements. Today's networks do a poor job of identifying which 
traffic is associated with which service. Therefore, applications vie for whatever network resources can be 
obtained in a first-come, first-served fashion. 

H. Traffic patterns are shifting from the traditional telecommunications model where the community of interest was 
primarily local to one where the community of interest is distance independent. 

I. Today's network is not able to measure or monitor the statistics of layer-2 and layer-3 traffic types and take 
advantage of dynamic network capabilities to add network resources to support customer Service Level 
Agreements (SLAs). 

The invention is similar to FAST with respect to the separation of signaling and switching and interaction with policy 
servers. This disclosure extends these concepts to IP connectionless protocols as well as higher layer session and 
application layer protocols. 



2. Describe how the invention qualifies as a solution to the problem, and state the advantage of the item over presently 
known devices, systems or processes. 
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InnJ^fpAMnt^r^f 8 ^ 6 '? ^1°^ muter M ° a pro 9rammable Access Network with distributed service 
control (PANDSC) and hardware/software Service Controllers (SC) executing on external processors as shown in 
Thf^o, 7 he SCS ' nterfaCe t0 the PAD usin9 a Messa 9e Control and Reporting Interface (MCRI). The PAD uses 
the MCRI to pass service-specific messages to/from the corresponding service controller software/hardware 
executing on an external processor. The PAD uses fields in the network, transport and application layer headers to 
idenhfy a particular traffic flow and determine which messages are passed to a specific service controller One or 
more service controllers may remotely control a single PAD; however, only one SC would control a particular traffic 

P S repo K on events of statistics of received * afflc accordi " * t^^ZZ 

intervals defined by the SC. The combination of the PAD functions of service-specific message forwarding remote 
con rol, and reporting enables the implementation of the service controllers by different vendors than those 
implementing the PAD. 



External Service Control of 
Program mable Access Device 
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B. The invention achieves superior scalability when compared with traditional routers since it separates out the 

functions performed by a router into three platforms. Routing is still done in the router as shown on the right-hand 
side of Figure 1L However, the functions of filtering, message forwarding, policing, and marking are placed in the 
PAD. Finally, the message interpretation, signaling, admission control, and policy invocation is implemented in 
SCs on external processors. 

°' I™ t P rT mab i e A fS 8 Device and SC enable c " s to m er applications to reserve bandwidth, perform admission 
control, and pnontae traffic streams based upon available capacity and policy controls. These policy controls may 
be initiated by the provider or the customer organization. The capability for customer applications to interact with 
service provider network resources provides the customer the ability to dynamically provision services as well as 
provide applications the required quality of service guarantees. If the PAD is located at the extreme edge of the 
ne^ork, then the external processor can signal for access capacity. This network-based provisioning invoked by 
policy control replaces time-consuming and error-prone OSS provisioning. 

D. The IP filter in the PAD provides the ability to identify higher layer message types (network, transport and 
application layers) and forward those messages from/to the external processor based on the parameters 
configured by message processor. The IP filter will have the ability to use a combination of protocol type SA DA 
TOS or DSCP, SP, DP and other fields to distinguish different message types. ' ' ' 

E. Each service controller executing on the external processor supports a specific type of service. (Each service 
controller may be based on a generic controller with service-specific APIs.) The invention allows implementation of 
"7™^ b V m introduction of new SCs (or modification of existing SCs) without requiring changes to the 
PAD Multiple service controllers provides the ability to add new services or modify existing services by the 
addltl0n or ^Placement of service controllers rather than requiring all services to be disrupted during upgrades 
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SCs can be installed on multiple external processors. Additional external processors are easily added accordinq to 
service requirements, which results in the good scalability. 

. The external processors provide added security against theft of services and attacks. The external processors may 
be maintained in a secure environment while leaving the forwarding functions of the PAD in a less-secure 
environment. In addition to being physically separate from the PAD, security software and/or hardware on the 
external processor may be implemented. TCP sessions to configure the PAD from the IP addresses other than its 
master external processors would be denied by the IP Filter. 

. Since the PAD intercepts network, transport and application level messages, it enables the identification of 
applications and users, and sets up an appropriate priority or provides the desired bandwidth to the data flows of 
user applications. For example, RSVP together with Microsoft subnet bandwidth manager (SBM) provides an 
application with guaranteed bandwidth and priority end-to end across the local and wide area networks. 

. As Internet traffic patterns change to be well-distributed around the globe, the ability to apply service and policy at 
he access separately from routing on a regional basis provides a more scalable design for forwardinq traffic 
toward the distant destination. 

The usage monitor in PAD is able to track the statistics of different layer-2 and layer-3 traffic types. When the volume of 
h-affic for a specific type across a threshold, this event is reported to SC. The Signaling Processor within the External 
Processor works with the SC to ensure that active SLAs are maintained throughout the network. This coupling of the 
policy accessed by the SC and the dynamic SLA support in the network provides a more flexible solution that is 
available with today's TDM approach to SLAs 
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P fnZtl ?r t ° f th tM 6SS SyStem im P |ementin 9 the PAD and SC concept. The Access system includes an External 

?ontmT a nH R.nL f^T^f™ {S ^'' Ce P °' iCy lnterfaCe) iS the interfaCe between Poiic V Serve? ™<« SCs. MCRI (Message 

Control and Reporting Interface) is the interface between SCs and PAD. Detailed descriptions of these components ■ ■ ■ - 9 



Jntert^l^!!?! a L 9en6ra! P 7,? Se COm h PUter f nd/ ° r 3 SpeCia ' PUrp0Se hardware t0 P rovidin 9 environment for one or multiple SCs and 
1^1 c f t A Se 1 ICe C f ntr °" er 03,1 be im P' emented ei'her by hardware or by software. A service controller is able to interpret 

service-specific messages and invoke the appropriate policy control and network si " 



laling procedure. The s< 



e controller configures the PAD 



performance of the PAD. In fact, SCscan be allocated to external processors and PADs in an arbitrary manner in resonnss to 9m « t„ 
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(Fig ure A.1 External Service Control and PAD) 



Inventor Signature ^ Date " I nventor Signature Pate I Inventor Signature 

Print Name T^„| f_ ^ fyy^ | Print Name |>( LaTl^«i | Print NamV 7 / f=, 



MCI WorldCom Confidential 



EXHIBIT A 



A.2 Programmable Access Device (PAD) 




c forwarding, marking, policing and 



InLo? F H et ° per f 65 ° n ! h ! DA ' SA ' TOS > SP ' DP and other fields of a P ack0t ^ceived from a user device and is configured by the 
control interface. It either directs a packet to a specific marker/policer, or else redirects the packet to the message interface. The message 
interface may also inject a packet into the Packet Header Filter. "»»<*9« 



The policer applies one or more token or leaky bucket algorithms to the stream of received pi 
parameters established by the control interface. The results of the policing function can be di 
nonconforming packets, or counting of nonconforming packets. 



sts to determine conformance to traffic 
•d of nonconforming packets, marking of 



The marker function sets the bits in the DiffServ/TOS byte, and/or the 3-bit MPLS experimental field, and/or the 20-bit MPLS label field and/or 
other fields for a specific flow as configured by the control interface. 

The Usage monitor tracks the statistics of different layer-2 and layer-3 traffic types. Thresholds and other criteria can be set up to invoke a 
S!,?, reP0 ^ 9 , messag , es sent to the SC ma V summarize the usage information for a customer, report the occurrence of a high- 

pnonty traffic flow or warn the large volume of out-of-band traffic etc. 

Output buffers can be a single large buffer or distributed multiple buffers. A percentage of the total buffer or a fixed amount of buffer can be 
assigned to a class of traffic or a traffic flow classified by DA, SA, TOS, PT, SP and DP. Packet scheduler applies Weighted Round robin and 
other algonthms to support statistical multiplexing. The combination of the buffering mechanism and scheduling mechanism can put a limit on th« 



:o transmit a packet over the PAD. 



The Shaper discards the nonconforming packets, sends marked packets to appropriate queues, and controls the delay jitter of a flow. 

Forwarding table keeps entries for each forwarding path. A forwarding path is represented by the packet flow attributes ie DA SA TOS PT 
SP, DP, the incoming port and the corresponding output port. ' ' 
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A.3 External Processor 



External Processor 




Message Control & V — J — 
Reporting Interface \J 



(Figure A.3 External Processor) 

Figure A.3 illustrates the logical elements within the External Processor. The External Processor is composed of several control and process 
functions that are utilized by policy servers and PADs to determine and affect the appropriate processing of packets and messages to and from 
customer applications. 

PADs send messages, report information and control commands to the External Processor through the Message Control & Reporting Interface 
(MCRI). The Message Processor, Reporting Processor and PAD Controller utilize the MCRI. 

^■■■■MfcThe Report Processor is able to configure the reporting functions of the PAD inciudingthetypeofreportJngm 
content in the reporting message, whether to pass or not pass report information, etc. The Message Processor is able to configure the'lP filter to 
pass or not pass specific messages based on SA, DA, PT, SP, DP and/or other fields. 

The PAD controller configures and manages the PAD. The PAD Controller operates on the PAD Forwarding table, IP filter Usage Monitor 
Marker/Policer/Shaper, Buffer and Scheduler by commands or scripts. 

The Signaling Controller supports signaling protocols (e.g. RSVP, LDP, PNNI, FR UNI, ATM UNI, etc.) to set-up or tear down a VC or LSP across 
the network. The VC or LSP may have QoS specification with it. 

The Service Controller (SC) is the main control module for each service. It translates the messages from the Message Processor and Reporting 
Processor into appropriate policy queries and sends them to the PDP. It launches VC or LSP setups across the network through the Signaling 
Controller. It configures forwarding table, IP filter, Marker/Pol icer, Shape r, buffer and scheduler on a PAD by the PAD controller. All these working 
together delivers the desired service for the customer traffic. ^■■■■MBHBV'HHMHBBiiM^BIHBHMflBHHMIBi. Each 
PAD has at least a primary and secondary SC. If a PAD lo ses cont act with the primary SC contact will be initiated with the secondary SC. The 
PAD will report state information to the secondary SC. VltfH^MMMMBHMHMMlVHttHI^Bi 

To reduce the number of messages passed between a SC and the PDP, SCs^WMBcache the frequently used policy lookups in its 
policy caches. For an incoming policy query, a SC looks up its policy caches first before it sends the query to the PDP. When a SC directly 
queries the PDP for a new service request, the SC may also request the PDP to dump all the related policy information from the policy database 
to its policy caches. Caching enables subsequent policy queries to utilize information that has already been retrieved recently from the policy 
server and reduce the message traffic between the SC and PDP. However there is a tradeoff between the number of direct policy queries and 
the cache refresh frequency and the amount of policy information downloaded from the PDP at each refresh. The objective would be to cache the 
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policies for IP services requiring intensive policy queries, such as SIP calls. There would be no need to cache the policy lookups for a TCP 
session that issues only one policy query in its lifetime. 



The PDP within a policy database interacts with a SC by utilizing the Service Policy Interface (SPI). With the SPI, a SC is able to use COPS, 
LDAP and other policy query protocols to query the PDP within the policy database. The policy database resides on a policy server which would 
be an external processor resident on hardware separate from the External Controller and placed in different locations within the network. The SC 
sends policy requests to the PDP. The PDP returns the policy decisions for each request. The policy decision can be "approve", "reject" o 
configuration parameters for the SC and PAP. The PDP maintains usage information ur " — ' ' ' ' """" ' ' — ' — ~ 



With open SPI and MCRI, the carrier administrator should have the full control of the SCs and programmable access devices by writing scripts 01 
configuring parameters. Customers could also be granted limited control over the SCs and PADs in support of self-provisioning. 
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A.4.1 Service Policy interface (SPI) 



Set Inactivity Timer 

Approve the transaction 

Reject the transaction with a cause indication 

Return parameters in response of request 

Dump the policy lookups into SC policy caches 

SC to PDP 

Translate Signaling Messages into appropriate Policy Queries, e.g. RSVP -> COPS (RSVP) SIP-> COPS (SIP) 

Query Policy Requirements 

Set the flag for caching of Policy lookups 

Translate Policy Decisions into appropriate control commands 

A.4.2 Message, Control and Reporting Interface (MCRI) 

PAD to External Processor 

sing 

s based upon SA, DA, PT, SP, DP, and/or other fields such as TCP Flags (SYN, ACK, RST, FIN, ...) 



TCP Retransmit Threshold Crossed 
Inactivity Timer Expired 
Activity Detected 
Keepalive/Heartbeat Exchange 
State synchronization in event of SC switchover 
Traffic Threshold C 
Usage Statistics 



External Processor to PAD 

• Message Passing 

Inject packets into the user of trunk side interface 

Set pass/no pass flag based upon SA, DA/ PT, SP, DP, and/or other fields 

«■ Control 

Configure IP Filter 
Configure Marking 
Configure Policing 

Configure Output buffers & Scheduler 
Configure Shaper 

Drop multicast packets from a source 
Admit/Deny Source Routing Option 
Set TCP Retransmit Reporting Threshold 
Set Inactivity Timer 
Set Activity Timer and Level 
Configure Forwarding Table 
Set Traffic Reporting Threshold 

Allocate Resource (Bandwidth, Queue & CPU time) to a customer, a flow, a route or a multicast tree 
Set Reporting Flags (True/False) 
Set SVC, PVC or LSP 

A.4. 3 PAD-SC Switchover Operation 

To prevent the interruption of the service, the PAD will switch to a backup SC in the event of a fault in the primary SC or the loss of connectivity 
to the primary SC. The PAD uses a reliable communication protocol (e.g. TCP session) to exchange information with SCs The KeepAlive 
message is exchanged between the PAD and a SC periodically to keep the TCP session active. When the KeepAlive message timeouts the 
PAD detects the failure of the SC. The PAD starts setting up a new TCP session with the secondary SC. if the PAD could not connect with the 
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secondary SC the PAD would stop accepting new sessions and keep the state and the service for all the activesessto^fte^P TCP ~««i„n 

t^to™s£SZ 9 £T'p%> - S eS,ab ' iS H f , the PA ° StartS UPl0adin9 thS State informati0n 0f ^ ~ss^ « ^ 2 
L» ith , ?k secondary The PAD ,s re 9wrecf to keep the state machine for each active session. (See Figure A 4 The PAD successful 
sw,tches from the primary SC to the secondary SC after detecting the failure of the primary SC) successfully 



PAD-SC Switchover Due to the Failure of the Primary SC 



Primary SC pad Secondary SC 




6. Upload Active : 



(Figure A.4 The HAD successfully switches from the primary SC to the secondary SC after 



detecting the failure of the primary SC) 
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PAD-SC Switchover after Primary-SC is Restored 
Primary SC pad Secondary SC 




(Figure A.5 PAD Restores Connection with Primary SC) 
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A.5 Examples 



rZ e lt f ampl f es m t Pr ° Vided be ' OW t0 HIUStrate how various network activities ™V be supported by the components of the proposed invention 
PAD- The Programmable Access Device as described is section A.2. 

^J^^^^StlZ r" 68 ^ P ° liCy M "**» to - d *»" ™ P » * ^ Service 

?a^?£™ ^ T^T ^ 0r SWitCheS Within the service provider network that would ^ send a message or 

The following examples are provided in the sections that follow: 

Network-Level Signaling Example 
RSVP Signaling Example 

Connection-Oriented Transport Examples Using TCP Sessions 
TCP State Machine on the PAD 
TCP Session Establishment 
TCP Session Close 
TCP Session Unauthorized 
TCP Session Timeout 
TCP Session Abrupt Close 

Connectionless Transport Examples Using UDP Reporting Function 
UDP Reporting Successful 
UDP Reporting Unauthorized 
UDP Reporting Timeout 

Application-Level Examples Using SIP Signaling 
SIP Call Establishment 
SIP Call Termination 
SIP Call Timeout 
SIP Call Negotiation 

Multicast Examples 
Authorized Registration of a New Multicast Group 
Unauthorized Registration of a New Multicast Group 
Authorized Membership Query 
Unauthorized Membership Query 
Authorized Sending of Multicast Packets 
Unauthorized Sending of Multicast Packets 
Receiving Authorized Multicast Packets 
Receiving Unauthorized Multicast Packets 
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A.5.1 Network-level Signaling Example 



the RBS to the customer (4). The RBSC returns PATH (5™ PAD PAD . senoJ Uie PATH ^enes the POP (3). The POP approves 

network. The receiver responds by a reservation (RESVime^nP m rZ vln PATH ( 6) message downstream to the other end of the 
query (9). The POP apples znleZr™^^ «*S£ which invokes another poiicy 

aNocated bandwidth for a customer. The occupied bandwidt is wr^t^ Sft ft P ^22'^^-^ at <he PDP keepS track of the 
admission decision.) The RBSC then kicks off either the ATM sia^inn or fhf Jp? ^ bandwidth to a customer for policy-based 

connection is confirmed (12), the RBSC configu e f he PAO s ?p 2" and ^JS^Z^ ? * SV ° °' 3 LSP (1 1) ' After the 
SVC or LSP (13). The RBSC in turn returns RESV < (14) t , th f PAD ^S^^nf p^^" 1 PaCk6tS ° f m f ' 0W 0ver the established 
RBSC also sends the CONFIRM downstream to ^^1^ ( f 5) T tream to the sen ^r application. The 

filter in PAD captures RSVP messages accoTd ng to ZXSt^^) ^ ^ SV ° ° f the LSP ' Ws 'P 



RSVP Signaling Example 



Customer Site PAD 

1 . RSVP PA 
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(Figure A.6 RSVP Signaling Example) 
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A.5.2 Connection-oriented transport examples using TCP s< 
• TCP State Machine on the PAD 



TCP STATE MACHINE I Service 
» Controller 




(Figure A.7 TCP State Machine) 
The TCP state machine on the PAD has two states: idle and active. The state transition is described below: 
IDLE -> ACTIVE 

1 . When the state machine is in the idle state (non-existing TCP session), it passes and only passes the first SYN message received from the 
" s . e '" e 5JU 1 - a) - The SC queries the policy server for P° lic y decisions for this TCP session after it receives the SYN message from the 
PAD. If the TCP session is approved, the SC returns the SYN message back to the PAD (1 .b). The PAD changes the state machine to the 
active state and forwards the SYN message to the receiver to complete the three-way handshake (1.c, 1.d). The PAD passes the ACK 
message representing the success of the handshake to the SC (1 .e). The SC knows the TCP session is open and adds the TCP session 
into its active session table. The SC updates the PAD with an inactive timer and other related parameters of this TCP session and then 
sends the ACK back to the PAD (1 .f). The TCP session is ready for data transmission (1 .g). 



a FIN message from the either side of a TCP connection for an active TCP session it resets the TCP state 
machine to be idle (2.a). The PAD passes the FIN message to the SC (2.b). The SC learns that the TCP connection is inactive and deletes 
he TCP session from its active session table. The PAD forwards the FIN message to its destination to complete the three-way handshake 
tor closing the TCP connection (2.c, 2.d). The PAD deletes the state machine of the TCP session 

When the inactive timer on the PAD for an active TCP session expires, the PAD resets the TCP session to be idle (3.a). The PAD reports 
the timeout error to the SC (3.b). The SC deletes the TCP session form its active session table and updates the PAD. The PAD deletes the 
state machine of the TCP session. 

When the PAD receives a RST segment from either side of a TCP connection, it knows that an abrupt close is requested and resets the 
TCP session to be idle (3.a). The PAD reports the timeout error to the SC (3,b). The SC deletes the TCP session from its active session 
table and updates the PAD. The PAD deletes the state machine of the TCP session. 
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TCP Session Establishment 

fSffl TZt rn A nP°PKm/ CP SYN H r SSa9SS f0r non " exis « n 9 TCP sessions to them. In the example shown in Figure A.6, The client 
" * '? f v , (1 ) C ° mmand th3t t6llS TCP that " wants t0 °P en a connection to a server at a given port and IP address. The 
chent TCP picks an initial sequence number (800 in this example). The client TCP sends a synchronize segment (SYN) carrying this 
sequence number (2). When the SYN arrives, the PAD detects that it is a mission-critical e-oommerce TCP session based on the 
FrlrlTJ^fn 8S 1 P ort " umber < PT=6 - PORT=80). The PAD passes the SYN to the e-commerce service controller (ECSC) (3). The 

TCpi5on% Th. Prlr h T^vk?? - T the PDP (4) USing LDAP 0f SOme oth9r policy que ^ protoco1 ' The PDP approves the 
I OP session (5). The ECSC sends the SYN back to the PAD (6). When the PAD receives the SYN from the ECSC, it spawns a new TCP 
state machine and sets it to an active state (7). The PAD sends the SYN downstream to the server (7). When the SYN arrives the server 
In ACK of 8m^ m S 0 T n n ?H 7.T 5 r f ( f 2°.'" The SerVer TCP sends a SYN se 9 ment containin 9 initial ™^™e number 400 and 
rllnPSi S I , T^o 6 St I 313 byt6 Sen * by the dient should be umbered 801 . The SYN/ACK message is sent back to the 
fTdSl "hvS ^.S hv T reC h e ' V ?H S i 6 S6 T r 3 SYN/ACK message ' the client TCP returns an ACK of 401 ( 10 >- whlcn means that the 
SvSS^ S ?7 er ^ U ^ numbered 401. The PAD passes the ACK to the ECSC (11). The ECSC learns that the three- 
Zl pad m 3 J si si T an f d ^ TCP S6SSi0n iS ° pen ' The ECSC adds the TCP session int0 its active sessi0 " table and configures 
tpp Hi IT ■? "^missions and the inactive timer. The ECSC also sets the marker to mark the packets belonging to 
TCP £eJ ! Z %r Q P f ri0rity ' K° r ,o° c m , e ap P |ications ' sucn as the *ra>n'n9 applications that will only allow the teacher to disconnect the 
LndsTTri fn ,1 H C °r f< f -!° ^ the ^ FIN -> The ECSC then returnS tne ACK se 9 ment to the P ^D (13). The PAD 

ZritT! n ? 1 destination server (14). The client TCP notifies its upper layer application that the connection is open (15). The client 
and the server start exchanging data in the TCP session (16). 



TCP Session Establishment Example 

PAD ECSC PDP Networl 



Customer Site 
(Client) 



(Figure A.8 TCP Session Establishment Example) 
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TCP Session Close 

Either side of a TCP connection can launch a close. The server initiates the close in the example shown in Figure A.9, The server 
application has finished its work and tells TCP to close the connection (1). The server TCP sends a FIN segment (2), informing the partner 
that it will send no more data. The PAD resets the state machine of the TCP connection to be idle and passes the FIN segment to the ECSC 

(3) . The ECSC deletes the TCP session from its active session table and configures the PAD to stop marking packets for this TCP session 

(4) . The PAD forwards the FIN segment to the client (5). The client TCP acknowledges receipt of the FIN segment (6, 7). The client TCP 
notifies its application that the client wishes to close. The client application tells its TCP to close. The client TCP sends a FIN message to 
the server TCP (8,9). The server TCP receives the client's FIN and responds with an ACK to the client (10). The PAD knows the three-way 
handshake for closing the TCP session is successful and deletes the state machine of this TCP session. The PAD then forwards the ACK to 
the client (11). The server TCP notifies its application that the connection is closed (13). 



TCP Session Disconnect Example 

Met 
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(Figure A.9 TCP Session Close Example) 
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TCP Session Unauthorized 

In the example shown in Figure A. 10, the client application issues an OPEN (1 ) command that tp p th . •» 
to a server at a given port and IP address The client TCP Dicks an initial in? k ™ , at " wants to open a conn ection 
(SYN) casing this sequence number (2 £n teSYN sTgmen bZsTpTd!^ that it KiT— r" T*™*" 
session based on the destination IP address and port number (PT-6 PORT-Rm rL D*rf 1 mission-cntical e-commerce TCP 

TCP session in this example.) SYN S69ment from the ECSC ' no state machine has been created for the 



TCP Session Unauthorized Example 



Customer Site PAD ECSC 
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^N,1.TCP OPEN 
2. TCP SYN 
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i S. LDAP-DENY 
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(Figure A.10 TCP Session Unauthorized Example) 
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TCP Session Timeout 

Normally, TCP sessions have a proper disconnect. However, in the event a server fails or reboots or the network breaks the TCP session 
is going to timeout in the host. In this case, normal disconnect will not occur. Other means must be used to update the ECSC to the inactive 
state for this session. In the example shown in Figure A.1 1, the route to the TCP partner is disrupted by loss of a link or a node (1) The 

k*! T .u Stal1S re - transmittin 9 the same data. After reaching a threshold number of retransmissions (2,3,4), the client TCP timeouts and 
aborts the connection (5). Subsequently, the inactive timer in the PAD expires. The PAD updates the TCP session to an inactive state and 
reports the TCP session timeout error to the ECSC (7). The ECSC deletes the TCP session from its active session table and configures the 
PAD to stop marking the packets for the TCP session. The PAD deletes the state machine of the TCP session. 



TCP Session Timeout Example 



Customer Site 
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2. RETRANSMIT 



CONNECTION 



(Figure A.11 TCP Session Timeout Example) 
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TCP Session Abrupt Close 

Either side of a TCP connection can launch an abrupt close. This may be done because the application wishes to abort the connection or 
because TCP has detected a serious communication problem that can not be resolved. An abrupt close is signaled by sending a RST ' 
segment to the partner. The server initiates the abrupt close in the example shown in Figure A.12 (1,2). The PAD resets the state machine 
for the TCP session to be idle and passes the RST segment to the ECSC (3). The ECSC deletes the TCP session from its active session 
table and configures the PAD to stop marking packets for this TCP session (4). The PAD deletes the state machine of the TCP session and 
forwards the RST segment to the client (5). The client closes the TCP session upon receiving the RST segment (6) 



TCP Session Abrupt Close Example 



Customer Site PAD ECSC PDP Network 

(Client) (Server) 
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(Figure A.12 TCP Session Abrupt Close Example)" 
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A.5.3 Connection-less transport examples using UDP reporting function with specific port number ranges 



UDP Reporting Successful 

Section A.5.1 gives an example of RSVP signaling where the customer initiates the RSVP messaging. In the example shown below in 
Figure A.13, the client computer in the customer site does not support RSVP. A user on the customer site invokes a client program to make 
an IP telephone call. The client process gets an unused UDP port from the pool of available ports assigned for voice data transmission. The 
client application starts sending voice data encapsulated by UDP packets over the network as best-effort traffic (1). The PAD detects the 
constant flow of UDP packets (PT=1 7) within the voice port range and reports the occurrence of voice data flow to the IP Telephony Service ' 
Controller (IPTELSC) (2). The IPTELSC queries the PDP for policy decision (3) using COPS or some other policy query protocol. The PDP 
finds that the customer ordered guaranteed service for his IPTEL calls and commands the IPTELSC to provide guaranteed service for this 
IPTEL session (4). The IPTELSC configures the PAD with an inactive timer for this IPTEL call and instructs the PAD to stop reporting the 
occurrence of this IPTEL session. The IPTELSC initiates a reserved bandwidth route setup process (6-16). For an ATM core, a bi-directional 
SVC is set up. For an MPLS core, two uni-directional LSPs are set up. After the QoS path is established, all the voice UDP packets 
belonging to the IPTEL session are transmitted through the same QoS path (17). The PAD will periodically generate RSVP refresh 
messages on behalf of the user. If the IPTELSC caches enough policy information on making admission control decision in the first search 
(3,4), the IPTELSC does not need to query PDP for the second time and 10,11 are optional. 



UDP Reporting Successful Example 
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(Figure A.13 UDP Reporting Successful Example) 
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UDP Reporting Unauthorized 

aets an u a nus!fd1 inp"™* IrnZu'^ 1 T °? a , oustomer Site inv0kes 3 client pr ° 9ram to make an IP tele P ho " e call. The client process 
gete an unused UDP port from he pool of available ports assigned for voice data transmission. The client application starts sending voice 

vol?n T * b I UDP , T ketS ° Ver thS netWDri( 38 best - effort traffic < 1 >- The PAD detects the constant flow of UDP packets within tL 
voice port range and reports the occurrence of voice data flow to the IP Telephony Setvice Controller (IPTELSC) (2). The IPTELSC queries 

r?ri^PT P f IS r ( I*'" 1 . C0P ? °?° me ° ther P0licy query protoco1 - The PDP flnds that there are no Q°S requirements for this 
PAR fmm inlrtL t! to™ n V , mfor ™ aii t on res P onse back to ^ * P ^SC (4). The IPTELSC configures the PAD to prevent the 

PtcSZToX pah °f a9 H^ ?K d ffin an " laCtiVe timSr f ° r th,s IPTEL CaN < When fhe inactive timer ex P ires - the configuration the 
IPTELSC made on the PAD is cleaned.) The UPD packets are sent as best-effort traffic (6,7). 
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(Figure A. 14 UDP Reporting Unauthorized Example) 
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UDP Reporting Timeout 

The UDP session inactive timer expiry can be caused either by normal completion of the UDP data flow, the break of the transmission links 
or failure of the end computers. In the example shown in Figure A.15, the client application on the customer site has finished the call and 
stops sending voire traffic (1 ). The inactive timer for the IPTEL call expires after a while. The PAD detects the timeout event and reports it 
? € \ IP T ELSC The IPT ELSC releases the SVC or LSPs for this call (3,4) and invokes the PATHTEAR to explicitly tear down the QoS 
path for the call (5,6). The IPTELSC then deletes this (PTEL call from its active session table. The IPTELSC configures the PAD to delete all 
the configured parameters for this call. 



UDP Reporting Timeout Example 
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(Figure A.15 UDP Reporting Timeout Example) 
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A.5.4 Application-level examples using SIP signaling 



- - »' eacn SIP message invokes a policy query to approve a capability set. To reduce thenumberof 

messages exchanged between the SC and the PDP, the SC requests the PDP to dump the policy lookups for the SIP requester into its 
policy caches in its first policy query for a SIP call. The SC then uses the cached policies to make decisions for the SIP messages The SI 
state machine resides on the PAD. Thus the PAD is able to decide whether it needs to pass the received SIP message to the SC and 
should try to avoid forwarding SIP messages to the SC whenever pr~ : 



SIP Call Establishment 

In the example shown in Figure A.16, a caller on a customer site issues a SIP INVITE request to the callee (1). When the PAD detects the 
INVITE request (according to the UDPrTCP port range that is assigned to SIP), it passes the INVITE request to the Conference Call Service 
controller (OCSC) (2). The CCSC sets the policy dump flag and queries the PDP for policy decisions using LDAP or some other policy 
query protocol (3). The PDP approves the SIP session (4) and dumps the policy lookups for the SIP caller into the policy caches of the 
CCSC. The CCSC returns the INVITE request to the PAD (5). The PAD forwards the INVITE request to the callee (6). The callee responds 
o he ca er via 200 OK message (7). Since there is no change in the SIP capability set the PAD forwards the SIP 200 OK message directly 
7 e n f" er ( 8 > and does not P ass * to the CCSC. The caller acknowledges the acceptance of the 200 OK message via an ACK request (9) 

n Th^f S thS ACK reqUeSt t0 the CCSC (10) - The CCSC queries its po,icy caches and a PP r o v es the final capability set of the SIP 
can I he CCSC adds the SIP session into its active session table and configures the PAD with an inactive timer and other parameters to 
facilitate the SiP call (1 1 ). The ACK is sent back to the PAD (1 2). The PAD in turn sends the ACK to the callee (13). 



SIP Call Establishment Example 



Customer Site PAD CCSC PDP Network 



gOLICY DOWNLOAD 



(Figure A.16 SIP Call Establishment Example) 
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SIP Call Termination 

a multi-party SIP conference 
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SIP Call Termination Example 
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(Figure A.17 SIP Call Termination Example) 
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SIP Call Timeout 

(1 ) In a SIP message, the ExpireTimer denotes the duration of the call before it expires. In the example shown in 

SIP application detects that the call has exceeded the allowed duration in ExpireTimer (1). The callee then issues a BYE request (2) 
The PAD passes the BYE request to the CCSC (3). The CCSC deletes the SIP session from its active session table and cleans its 
policy caches. The CCSC commands the PAD to delete the entire configuration for the SIP call (4). The CCSC also prevents the PAD 
from passing it subsequent SIP messages from the SIP call. The CCSC returns the BYE request to the PAD (5). The PAD forwards the 
BYE request to the caller (6). The caller acknowledges the end of the SIP session via a SIP 200 OK message (7). The PAD forwards 
e to the callee (8). 



the OK 



S IP Ca II Timeout Example (1) 
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4 
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(Figure A.18.1 SIP Call Timeout Example (1)— timeout delectedby the SIP application) 
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(2) In the example shown in Figure A.18.2, all parties of the SIP call die. The inactive timer of the SIP call expires (1). The PAD reports the 
timeout error to the CCSC (2). The CCSC deletes the SIP session from its active session table and cleans its policy caches. The 
CCSC commands the PAD to delete the entire configuration for the SIP call (3). 





SIP Call Timeout Example (2) 
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(Figure A.18.2 SIP Timeout ExampleTSP^AII parties in thelsFcall die and timeout is detected by PAD) 



inventor Signature Date 


Inventor Signature Date 


Inventor Signature Date 




duS&~~^ 




Print Name *>) ^ d fc, Rr T),^ 


Print Name (J , tee *T U » * $ 
MCI WorldCom Confidante! 


Print Name IJ£\ YAO 



EXHIBIT A 



SIP call negotiation 

In the example shown in Figure A.19, a caller on a customer site issues a SIP INVITE request to the callee (1). The PAD passes the 
INVITE request to the CCSC (2). The CCSC sets the dump policy flag and queries the PDP (3) with LDAP or some other policy query 
protocol. The PDP approves the SIP session and dumps policy lookups for the SIP call into the policy caches of the CCSC (4) The CCSC 
returns the INVITE request to the PAD (5). The PAD sends the INVITE request to the callee (6). Since the INVITE request specifies a 
bandwidth that is higher than what can be supported by the access link of the callee and requests a set of media encodings, the callee 
responds with a 606 Not Acceptable message (7). The response states that only 56 Kbps is available and that only PCM or LPC audio could 
be supported in order of preference. When the 606 response is passed to the CCSC (8), the CCSC queries its local policy caches and 
approves the new capability set. The CCSC sends the 606 response back to the PAD (9). The PAD forwards the 606 response to the caller 
(10). When the caller receives the 606 response, it adjusts the call capability requirements and issues another INVITE request (11) which 
specifies 56 Kbps bandwidth, LPC audio encoding and the ExpireTimer 120 minutes. The PAD passes the new INVITE request to the 
CCSC (12). The CCSC queries its local policy caches and approves the new SIP capability set again The CCSC returns the INVITE 
request to the PAD (13). The PAD sends the INVITE request to the callee (14). The callee is able to support all the call requirements except 
that it requires the call duration to be 100 minutes. The callee responds a 200 OK response with the ExpireTimer 100 minutes (15) The 
PAD passes the OK response to the CCSC (16). The CCSC checks the SIP capability set carried in the OK response and approves it The 
CCSC then sends back the OK response to the PAD (17). The PAD forwards the OK response to the caller (18). When the caller receives 
the OK response it modifies its ExpireTimer requirement to be 100 minutes and acknowledges via an ACK request (19) The PAD passes 
the ACK response to the CCSC (20). The CCSC approves the final SIP capability set carried in the ACK response. The CCSC configures 
the PAD with an inactive timer and other parameters to facilitate the SIP call (21). The CCSC then returns the ACK to the PAD The PAD 
forwards the ACK to the callee. After the caliee receives the ACK response, the SIP call is successfully established 



SIP Call Negotiation Example 
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(Figure A.19 SIP Call Negotiation Example) 
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A.5.5 IP Multicast Examples 



The current IP multicast uses an open group model.(| 

- — ^""^^^B^^BWWWtaBBBBHBMBHBBBHlr Multicast group members 
can join or leave a multicast group at will. There is no need to register, synchronize, or negotiate with a centralized group management entity 
However for a multicast service, the customers expect control and management of group membership for both the sender and receiver.«~ 




The proposed access system architecture in this p 
messages. 



ition enables policy-based multicast 



management by monitoring the IGMP 



Manage the registration of th 



m multicast groups 



(1 ) Authorized Registration of a new multicast group 

In the examples shown in figure A.20.1 , a host on the customer site signals an IGMP join-group Report message to the edge router (1 ) 
(on the right hand side of figure A.20.1 ). IP filter in the PAD captures the IGMP messages based on PT=2. The PAD forwards the join- 
group Report message to the Multicast Service Controller (2) (MSG). The MSC queries the PDP within the policy database with LDAP 
or some other policy query protocol (3). The PDP finds the sender's IP address in the eligible membership list and approves that the 
sender join the group (4). The Membership Report message is forwarded to the edge router (5,6). In case the sender is the first 
member of that group on the network, the router adds the group being reported to the list of multicast group memberships on the 
network on which the sender is attached (7). 



Authorized Registration of a New Multicast Group 




(Figure A.20.1 Authorized Registration of a new multicast group Example) 



(2) Unauthorized Registration of a new multicast group 

In the examples shown in figure A.20.2, a host on the customer site signals an IGMP join-group Report message to the edge router (1 ) 
(on the right hand side of figure A.20.2). The IP filter in the PAD captures the IGMP messages based on PT=2. The PAD forwards the 
join-group Report message to the Multicast Service Controller (2) (MSC). The MSC queries the PDP within the policy database with 
LDAP or some other policy query protocol (3). The PDP finds that the sender is not eligible to join the multicast group and rejects the 
join-group request (4). The MSC drops the join-group Report message and write into its event log a warning message (5) This 
prevents the unauthorized host from registering a new group in the edge router. 
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multicast group Example) 



(Figure A.20.2 Unauthorized Registration of 

Manage the host membership queries 

(1) Authorized Membership Query 

In the example shown in figure A.21.1, the PAD receives an IGMP host membership Query message from the edge router (1) It 
passes the host membership Query message to the MSC (2). The MSC queries the PDP with LDAP or some other policy query 
protocol (3). The PDP finds the source address for this query is the authorized edge router and PDP approves the Query (4) The h 
membership Query message is forwarded to the hosts in the customer site/sub-network (5,6). 



Authorized Membership Query 



(A.21.1 Authorized Membership Query Example) 

(2) Unauthorized Membership Query 

In the example shown in figure A.21.2, the PAD receives an IGMP host membership Query message (1). It passes the host 
membership Query message to the MSC (2). The MSC queries the PDP with LDAP or some other policy query protocol (3). The PDP 
finds that the Query is from an unidentified or unauthorized source and rejects the Query (4). The MSC drops the Query message and 
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Unauthorized Membership Query 



(A.21.2 Unauthorized Membership Query Example) 

Manage the sending of multicast packets to the network 

(1) Authorized sending of multicast packets to the network 

In the example shown in figure A.22.1, a host on a customer site sends IP multicast packets to the multicast groups When the PAD 
m 06 .'^/^ multlcast packet the lp fiifer captures the packet by checking its multicast address. The PAD passes the packet to 
he MSC (2). The MSG queries the PDP with LDAP or some other policy query protocol (3). The PDP finds that the source address of 
the P multicast packet is authorized for sending multicast packets to the multicast group and approves the sending of the multicast 
packet (4). The MSC configures the PAD to directly forward multicast packets to the edge router for the (source, multicast address) pair 
(5) and returns the first multicast packet to the PAD (6). The PAD forwards the multicast packet to the edge router (7) The PDP 
forwards all the following multicast packets for the flow directly to the edge router without passing to the MSC (8 9) 



Authorized Sending of Multicast Packets 



(Figure A.22.1 Authorized sending of multicast packets Example) 
Unauthorized sending of multicast packets to the network 

In the example shown in figure A.22.2, a host sends IP multicast packets to the multicast groups. When the PAD receives the first 
multicast packet (1 ), the IP filter captures the packet by checking its multicast address. The PAD p; 
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packets is unidentified or unauthorized and rejects the sending of multicast packets to the network (4^neMSCconfigures the pau to 
drop multicast packets for the (source, multicast address) pair and writes a warning message into the event log (5 6 7) This prevents 
the denial of service attack by flooding multicast packets onto the network. 



Unauthorized Sending of Multicast Packets 




(Figure A.22.2 Unauthorized sending of multicast packets Example) 
Manage the receiving of multicast packets from the network 
(1 ) Receiving authorized multicast packets 

!!?i he Sh ° Wn ' n fi9ure A ' 23 ' 1 ' the edge router receives IP multicast packets from the network and forwards them to the PAD. 

When the PAD receives the first multicast packet from the edge router (1 ), the PAD passes the packet to the MSC (2) The MSC 
queries the PDP with LDAP or some other policy query protocol (3). The PDP finds that the source address of the IP multicast packet 
was authorized for sending multicast packets to the multicast group and approves forwarding the multicast packet to multicast hosts in 
the customer site (4). The MSC configures the PAD to directly forward to the edge router multicast packets for the (source multicast 
address) pair (5), and returns the first multicast packet to the PAD (6). The PAD forwards the multicast packet to the multicast hosts in 
the customer site (7). The PAD forwards all the following multicast packets for the flow directly to the multicast hosts in the customer 
site without passing to the MSC (8,9). 
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Receiving Authorized Multicast Packets 



(A.23.1 Receiving Authorized Multicast Packets Example) 

(2) Receiving unauthorized multicast packets 

in the example shown in figure A.23.2, the edge router receives IP multicast packets from the network and forwards them to the PAD. 
When the PAD receives the first multicast packet from the edge router (1), the PAD passes the packet to the MSG (2). The MSC 
queries the PDP with LDAP or some other policy query protocol (3). The PAP finds that the source sending the multicast packets is 
unidentified or not authorized and rejects forwarding the multicast packet to the multicast hosts in the customer site (4). The MSC 
configures the PAD to drop multicast packets for the (source, multicast address) pair and write a warning message into the event log 
(5,6,7). This prevents the unauthorized multicast packets from flooding the sub-network in the customer site. 
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ACRONYMS 



ACK 


Acknowledgement 


API 


Application Programming Interface 


ATM 


Asynchronous Transfer Mode 




Border Gateway Protocol 




Conference Call Service Controller 


COPS 


Common Open Policy Service 




Customer Premise Equipment 


rpn 


Central Processor Unit 


na 


Destination Address 


Diffserv 


Differentiated Services 


DP 


Destination Port Number 


DSCP 


Diffserv Codepoint 


ECSC 


E-Commerce Service Controller 


rmf T 


First ATM SVC Trial 




Finished 


FR 


Frame Relay 




Internet Group Multicast Protocol 


iGP 


Interior Gateway Protocol 


IP 


Internet Protocol 


IPTEL 


IP Telephony 


IPTELSC 


IP Telephony Service Controller 


LDAP 


Lightweight Directory Access Protocol 


LDP 


Label Distribution Protocol 


IPC 


Linear Predictive Coding 




Label Switched Path 


MCIW 


MCI WorldCom 


MCRI 


Message, Control, and Reporting Interface 


MPLS 


Multiprotocol Label Switching 


MSC 


Multicast Service Controller 


PAD 


Programmable Access Device 


PADC 


Programmable Access Device Controller 


PANDSC 


Programmable Access Device with Distributed Service Control 


PDP 


Policy Decision Point- 


PNNI 


Private Network-Network Interface 




Point of Presence 


PT 


Protocol Type 


PVC 


Permanent Virtual Connection 




Quality of Service 


OD 


Reserved Bandwidth Service 




Reserved Bandwidth Service Controller 




Reset 


R<5VP 


Resource Reservation Protocol 


RTP 


Real-time Transport Protocol 




Source Address 


SBM 


Subnet Bandwidth Manager 


SC 


Service Controller 


SIP 


Session Initiation Protocol 


SLA 


Service Level Agreement 


SP 


Source Port Number 


SPI 


Service Policy Interface 


SVC 


Switched Virtual Connection 


SYN 


Synchronizing segment 


TCP 


Transmission Control Protocol 


TDM 


Time-Division Multiplexing 


TOS 


Type of Service 


UDP 


User Datagram Protocol 


UNI 


User Network Interface 


WAP 


Wireless Application Protocol 
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From: 
Sent: 



Cc: 

Subject: 



'Brian F, Russell' 
'Dave.medysan'; 'steven.mccann'; lee.thoma: 
RE: patent application 



»; jim.daltonj 



Attached please find our consolidated comments . We divided the comments into general 
comments and detailed comments. The general comments are put into a separate document. 
Detailed comments are made in the draft document with our initials. We also made some 
changes in the drawings . 



Qfo. 



Toll Free 
Pass Code I 



EXHIBIT B 



Thanks again for your excellent work. 



lei .yao 

Cc : Dave.medysan; steven.mccann 
Subject: RE: patent application 

<< File: RIC00033 (44796) .doc >> << File: landscapedrawings.doc >> << File: 
portraitdrawings.doc >> Gentlemen, 

Please find attached an initial draft of the first patent application. I would appreciate 
it if you could forward a copy to Lee for his review, as I don't have his email address. 

I will continue working on the claims for the 3 additional applications while I await your 
comments. As you work through the document, please address the highlighted comments 
embedded in the text. Also, please consider whether the description is technically 
accurate and complete (whether it discloses to a person "skilled in the art" how to make 
and use the invention) and discloses the "best mode" , if any, in which the invention may 
be used. 

It would be helpful to me if comments for all the inventors can be compiled into either a 
single marked up version of the application or a single set of separate comments. Thank 
you for your assistance in the preparation of this application, and please contact me if I 
can resolve any issues that arise during the review process. 

Best regards, 
Brian F. Russell 

EXHIBIT C 

Felsman, Bradley, Vaden, Gunter & Dillon, LLP 
Suite 350, Lakewood on the Park 
7600B N. Capital of Texas Hwy. 
Austin, TX 78731 



(voice) 
(fax) 



. patent lawyers . com 
Lei Yao 



Thanks for the upda' 
Lei 



EXHIBIT D 

looking forward to read the application. 



Original Message-- 

From: Bria n Russell 
Sent: <WH0PHMPMi 
To: lei. yao 
Cc : Dave .mcdysan; Steven . mccann 
Subject: RE: patent application 

Lei, 

Just to update you on my progress on the applications, I have nearly completed a draft of 
the first application and expect to send you the draft for review next week. As we 
discussed, the all of the applications will contain the same basic description, but will 
differ in focus in the claims, summary and abstract. Hopefully, the commonality in the 
applications will facilitate your review. 

Best regards, 

Brian F. Russell 

Felsman, Bradley, Vaden, Gunter & Dillon, LLP 
Suite 3 50, Lakewood on the Park 
7600B N. Capital of Texas Hwy . 
Austin, TX 78731 



EXHIBIT E 



e) 



From: 
Sent: 
To: 
Cc: 

Subject: 



Brian F. Russell g 

dave.mcdysan; lei.yao^ 
lee.thomas; steven.mccann 
RE: patent application 



Gentle 



Just to update you on the status of the patent applications, I have unfortunately been 
unable to work on the patent applications since I received the information Dave McDysan 
provided because of additional duties I have had to assume since Andrew, the firm's 
managing partner, broke his back last weekend. 

Originally, I had anticipated completing all of the applications by MflHHMMflhttHfe 

Inowbelieve that I can have revised drafts of the applications to you for review by 



I apologize for the delay. 
Best regards, 
Brian F. Russell 

Felsman, Bradley, Vaden, Gunter & Dillon, LLP 
Suite 3 50, Lakewood on the Park 
7600B N. Capital of Texas Hwy . 
Austin, TX 78731 

(voice) 
(fax) 



EXHIBIT F 



.patentlawyers . com 



From; 
Sent: 
To: 
Cc: 

Subject: 

Follow Up Flag- 
Flag Status: 




Follow up 
Completed 



RIC00043.cla.doc 



u , Gentlemen, 
Best regards, 



Brian F . Russell 
Felsman, Brsrilp^ ^ 

fite 350 Br Se e i;oI a or; he GU f ^ & LLP 
7600B N Can-it;,! * ~ Park 
Austin, T f %%j ° f exas Hwy. 

* (voice) 
» (fax) 




EXHIBIT G 



From: 
Sent: 



Cc: 

Subject: 



Follow Up Flag: 
Flag Status: 



Brian F. Russell f 

dave.mcdysan; lei.yao 
lee.thomas; steven.mccann 
RE: patent application RIC00033 

Follow up 
Completed 



landscapedrawings. Overview. ppt portraitdrawings.do 



RIC00033 
(44796).doc 



RIC00042.cla.doc 



Attached, please find attached the folic 



tng: 



(1) the second draft of the patent application, which includes your most recent comments 
[Please see my imbedded notes and questions pertaining to the "Overview" description that 

was added] and a full claim set; 

(2) figures for the application (which are unchanged except for the insertion of reference 
numerals in the "Overview" drawings provided by Dave) ; 

(3) claims, abstract and summary for the second application covering the PAD (Docket No. 
RIC00042) . 



I will send the claii 
today or 



Best regards, 



abstract and 



ry for the other two applications either late 



Brian F. Russell 

Felsman, Bradley, Vaden, Gunter & Dillon, LLP 
Suite 350, Lakewood on the Park 
7600B N. Capital of Texas Hwy. 
Austin, TX 78731 

(voice) 
(fax) 
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' . patentlawyers . co 



To: 
Cc: 

Subject: 



Brian F. Russell'; dave.mcdysan 
lee.thomas; Steven. mccann 
RE: patent application RIC00044 



EXHIBIT I 



Brian, 

Thanks for putting together all four applications during the short period. 
Steven, 

I will coordinate with Dave and Lee to review these applications. After the applications 
have been agreed on by us, do we need approval from you before we really submit these 
applications? What is the next step from the legal department? 

Thanks . 
Lei 

Original Message 

From: Brian F. Russell HMNI^PMMHMMl^BHB'^MMBM'Mfli 

sent: MNH^nvHHMMBViiw59K553fc 

To: dave.mcdysan; lei.yao 

Cc: lee.thomas; steven. mccann 

Subject: RE: patent application RIC00044 

<< File: RIC00044.cla.doc >> Gentlemen, 

Please find attached the claims for the final patent appliication covering the MCRI . 

Best regards, 

Brian F. Russell 

Felsman, Bradley, Vaden, Gunter & Dillon, LLP 
Suite 350, Lakewood on the Park 
7 60 OB N. Capital of Texas Hwy. 
Austin, TX 78731 

W g> (voice) 
iMWIi (fax) 



EXHIBIT J 



www . patentlawyers . com 



From: 
Sent: 
To: 
Cc: 

Subject: 




'paul.robert; 

'd ave . m cdysat 

patent applications 



Paul, 



made for the patent applications prepared by 
se representing Steven. The 



Attached please find the final comments 
Brian Russell. We understand that you will wo 

applications were well written. We only made several minor changes. If you turn on "track 
change" options of MS Words, you should beable to see those changes. We believe that the 
applications are ready to be submitted. '" ~ " 



Please let us know your thoughts 
Thank you very much. 



EXHIBIT K 



Sent: 

To: 

Cc: 

Subject: 



lei.yao 

dave.mcdysan; lee.thoma: 
Re: Patent applications 



Thank you for your assistance in preparing the patent applications. I have reviewed the 
comments you had and have finished incorporating them into the applications. 

To speed up preparation of the legal documents that will accompany the applications, I 
need updated addresses for each of you (the ones listed in the disclosure seem to be out 
of date) . 

Thank you for your help. 
Best regards, 
Brian F. Russell 

Felsman, Bradley, Vaden, Gunter & Dillon, LLP 
Suite 350, Lakewood on the Park 
7 60 OB N. Capital of Texas Hwy. 
Austin, TX 78731 

(fax) 

. patent lawyers . com 
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Receipt is acknowledged of this nonprovisional Patent Application. It will be considered in its order and you will 
be notified as to the results of the examination. Be sure to provide the U.S. APPLICATION NUMBER, FILING 
DATE, NAME OF APPLICANT, and TITLE OF INVENTION when inquiring about this application. Fees 
transmitted by check or draft are subject to collection. Please verify the accuracy of the data presented on this 
receipt If an error is noted on this Filing Receipt, please write to the Office of Initial Patent 
Examination's Customer Service Center. Please provide a copy of this Filing Receipt with the changes 
noted thereon. If you received a "Notice to File Missing Parts" for this application, please submit any 
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the Notice, the USPTO will generate another Filing Receipt incorporating the requested corrections (if 
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ltem 1 ■ Provide a short, descriptive title of the invention: 

Distributed Programmable Access Device Network Supported by Separate Service Controllers 

' tem «pbs): nd Und6r ^ drCUmStan0eS WaS the invention first ^ved (If you have any written evidence of this date, include 

I^ilT," °H n , WaS T ° Ut ° f initiativeS Within the Com P an y to provide customers with integrated access to all Company 
services and to provide customers with dynamic capabilities to adjust their services, either in type or quantitv TheTZr^ 
work in it he Next Generation Switching and Control group and developed this invent on white Sing on various P Xt 

Item 2b. What is the date of the first sketch or drawing of the invention- 

January 4, 2000 

Item 2c. What is the date of the first written description of the invention- 

January 4, 2000 

Item 2d, What is the date of the first test of or operation of the invention- 

Not Applicable. 

Item 3a. 



if nofLTrfw°'^ USe ° th ^ P3 "f i f ne ° essar y) to this conception of the invention and indicate the contributor's company 
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* P,ease record y° ur name correctly: Last Name, First Name, Middle Initial; DO NOT USE NICKNAMEs"et'c. 

Phone#: (w)_972.729.1288 (h) . Dept/Lo 

Current Address: _901 International Place Richardson_ 



_dave.mcdysa 



Street city S tale~ 



_75081_ 



Job Title: _ 



Job assignment at invention conception: Next Generation Switching_ 



Printed Name: Thomas_ 



Last name Firet ""Middle initial 

Phone#:(w}_314.216.1308 (h) _314.256.7112 Dept/Loc: _2042/XA5__ E-MaiHD: Jee.thomas@wcom.com_ 

Current Address: _One Brooks Center Parkway, Town&Country__ .MO 63017 

Street Ci ty State" ZipcodS~ 

Country: _USA Citizenship: _ US A job Title: Senior Engineer_ 

Job assignment at invention conception: __Next Generation Switching 
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Today's routers implement the routing, forwarding, policy, policing, marking, and admission control functions in a 
monolithic, proprietary manner. A few routers have limited implementation of external policy control. The services 
that a provider can offer are limited by the control software implemented by a particular router/switch vendor. If a 
service provider has routers from multiple vendors in a network, the proprietary services will not inter-operate. 
Consequently, the service provider is not able to purchase router/switches from one vendor and purchase policy- 
based service control from another vendor. Furthermore, a service provider cannot offer its network as a platform 
for a wholesale provider to offer value-added services utilizing the existing base network capabilities. 

The implementation of the multiple functions listed above in a monolithic router presents a significant scalability 
challenge for vendors in response to the phenomenal growth of Internet traffic. The current design approach by the 
industry separates the problem into core and access routers. Access routers perform the most complex functions 
and perform operations that simplify the tasks required of core routers. However, the monolithic design of access 
routers presents a limit for scalability of the Internet. Evidence of this fact is that the access router software image 



C. Another problem brought on by the rapid growth of Internet traffic is the need to dynamically provision, configure, 
and/or reallocate access capacity to IP-based services. Access capacity is often limited and a major cost 
component of modem networks. Therefore, it is subject to congestion and has a strong need for admission control 
and different levels of quality. Also, access products are not capable of handling a wide variety of traffic types while 
being able to enforce policy controls (provider-initiated or customer-initiated) or dynamic requests for capacity. 

D. Today's routers cannot distinguish between higher layer message types and forward the higher layer messages 
according to service/policy parameters. Today's routers do not use a combination of protocol type, source IP 
address (SA), destination IP address (DA), type of service (TOS) or differentiated service code-point (DSCP), 
source port number (SP) and destination port number (DP) to distinguish different message types. In fact, most 
routers use only the DA to make the forwarding decision. Some newer routers use only DA plus TOS/DSCP. 

E. Today's access routers have a concept of one controller providing all services for all message types. This results 
in a single complex router, which is difficult to add new services or modify existing services. This monolithic design 
limits flexibility and extensibility and increases cost. Evidence of this fact is that the time to market for new 
features and functions are delayed. For example, In today's network, if a service provider's external policy server 
sends COPS messages to an access router, the service provider must ask the vendor to develop a COPS 
interface on the router. 

F. Today's routers have relatively weak security control of their configuration information. For example, a command 
line interface is invoked by a simple userid password exchange in the clear when initiating over a telnet session. 

G. Desktop computing applications provide customers with the means to utilize many different services while each 
service requires different (quality of) service requirements. Today's networks do a poor job of identifying which 
traffic is associated with which service. Therefore, applications vie for whatever network resources can be 
obtained in a first-come, first-served fashion. 

H. Traffic patterns are shifting from the traditional telecommunications model where the community of interest was 
primarily local to one where the community of interest is distance independent. 

I . Today's network is not able to measure or monitor the statistics of layer-2 and layer-3 traffic types and take 
advantage of dynamic network capabilities to add network resources to support customer Service Level 
Agreements (SLAs). 

The invention is similar to FAST with respect to the separation of signaling and switching and interaction with policy 
servers. This disclosure extends these concepts to IP connectionless protocols as well as higher layer session and 
application layer protocols. 



2. Describe how the invention qualifies as a solution to the problem, and state the advantage of the item over presently 
known devices, systems or processes. 
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The invention decomposes the traditional router into a Programmable Access Network with distributed service 
control (PANDSC) and hardware/software Service Controllers (SC) executing on external processors as shown in 
Figure 1. The SCs interface to the PAD using a Message Control and Reporting Interface (MCRI) The PAD uses 
the MCRI to pass service-specific messages to/from the corresponding service controller software/hardware 
executing on an external processor. The PAD uses fields in the network, transport and application layer headers to 
identify a particular traffic flow and determine which messages are passed to a specific service controller One or 
more service controllers may remotely control a single PAD; however, only one SC would control a particular traffic 
flow. Additionally, the PAD can report on events of statistics of received traffic according to parameter ranges and 
intervals defined by the SC. The combination of the PAD functions of service-specific message forwarding remote 
control, and reporting enables the implementation of the service controllers by different vendors than those 
implementing the PAD. 



External Service Control of 
Program mable Access Device 
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B. The invention achieves superior scalability when compared with traditional routers since it separates out the 
functions performed by a router into three platforms. Routing is still done in the router as shown on the right-hand 
side of Figure 1 . However, the functions of filtering, message forwarding, policing, and marking are placed in the 
PAD. Finally, the message interpretation, signaling, admission control, and policy invocation is implemented in 
SCs on external processors. 

C. The Programmable Access Device and SC enable customer applications to reserve bandwidth, perform admission 
control, and pnontize traffic streams based upon available capacity and policy controls. These policy controls may 
be initiated by the provider or the customer organization. The capability for customer applications to interact with 
service provider network resources provides the customer the ability to dynamically provision services as well as 
provide applications the required quality of service guarantees. If the PAD is located at the extreme edge of the 
network, then the external processor can signal for access capacity. This network-based provisioning invoked by 
policy control replaces time-consuming and error-prone OSS provisioning. 

D. The IP filter in the PAD provides the ability to identify higher layer message types (network transport and 
application layers) and forward those messages from/to the external processor based on the parameters 
configured by message processor. The IP filter will have the ability to use a combination of protocol type SA DA 
TOS or DSCP, SP, DP and other fields to distinguish different message types. ' ' ' 

E. Each service controller executing on the external processor supports a specific type of service. (Each service 
controller may be based on a generic controller with service-specific APIs.) The invention allows implementation of 
new services by the introduction of new SCs (or modification of existing SCs) without requiring changes to the 
PAD. Multiple service controllers provides the ability to add new services or modify existing services by the 
addition or replace ment of service controllers rather than requiring all services to be disrupted during upgrades. 

Pate ' — — - 
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>n multiple external processors. Additional external processors are easily added according to 

,.,k;„i, u„ : n [ he good sca | ab j|j{y 

The external processors provide added security against theft of services and attacks. The external processors may 
be maintained in a secure environment while leaving the forwarding functions of the PAD in a less-secure 
environment. In addition to being physically separate from the PAD, security software and/or hardware on the 
external processor may be implemented. TCP sessions to configure the PAD from the IP addresses other than its 
master external processors would be denied by the IP Filter. 

. Since the PAD intercepts network, transport and application level messages, it enables the identification of 
applications and users, and sets up an appropriate priority or provides the desired bandwidth to the data flows of 
user applications. For example, RSVP together with Microsoft subnet bandwidth manager (SBM) provides an 
application with guaranteed bandwidth and priority end-to end across the local and wide area networks. 

. As Internet traffic patterns change to be well-distributed around the globe, the ability to apply service and policy at 
the access separately from routing on a regional basis provides a more scalable design for forwarding traffic 
toward the distant destination. 

The usage monitor in PAD is able to track the statistics of different layer-2 and layer-3 traffic types. When the volume of 
traffic for a specific type across a threshold, this event is reported to SC. The Signaling Processor within the External 
Processor works with the SC to ensure that active SLAs are maintained throughout the network. This coupling of the 
policy accessed by the SC and the dynamic SLA support in the network provides a more flexible solution that is 
available with today's TDM approach to SLAs. 



3. Specifically describe the item and its operation. Attach copies of drawings, sketches, prints, photographs and 

illustrations, which should be signed, witnessed and dated. Use numbers and descriptive names in descriptions and 
drawings. 



See attached. 



4. List all known and other possible uses for the item. 

PAD can be put in multiple places in the network to perform traffic management and policy control. The SCs are sized to 
meet the anticipated control and management traffic. The examples of the placement of PAD devices are 

A. Placement of PAD devices in access networks, i.e. fiber, xDSL, cable modem, WAP, etc. connecting customer 
equipment to a provider network controlled by regionally located external processor running SC logic. 

8. Placement of PAD devices at a provider's Point of Presence (POP) interfacing to a customer site over private line, 
FR, ATM, MPLS or an Ethernet access network. 

C. Placement of a PAD device facing a server farm that can be in the provider's POP or in the customer sites. 



5. List the features of the item that are believed to be novel. 

A. The concept of the separation of the service control and switching functions applied to connectionless IP services. 
Previously the state of art of separated control and switching applied only to connection oriented switching. 

B. By virtue of the separation of the PAD from the SC, traffic management and policy control occur much closer to the 
application than current network implementations achieve. 

C. Independent and distributed service control of the PADs results in several novelties. Multiple SCs per PAD means 
that new services can be implemented rapidly and independently of other existing services. Balancing of traffic 
load can also be done efficiently. Also, a single SC may control multiple small PADs to reduce the overall network 
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A.1 The Concept of External Service Control of a Programmable Access Device 

PmZtr S a h pIn=L C ° dTT ° f ,h x, AC ^n, S l yS,em im P |ementin 9 the PAD and SC concept. The Access system includes an External 
rnnt > h D . nd , a ^' ICy , SelVer - The SPI (Service Policy lnterf ace) is the interface between Policy Server and SCs MCRI (Message 
S th s secfen eP m9 > '* interface between SCs and p ™- Detailed descriptions of these components and interface contained 



intoJ T ' Pr ° cessor '? a general P ur P° se computer and/or a special purpose hardware to providing environment for one or multiple SCs and 
^TsSiT A 56 h IC6 TT* 03,1 te implemented either ^ ha *ware or by software. A service controller is able to interpret 

T°H e appropnate P° lic y control and signaling procedure. The service controller configures the PAD 

S2„SS^ * 7?Tl mS < reC T Ved fr0m P °' iCy SerVSr Via ^ SPL Separa,ion 0f the SC processi "9 from forwarding 

TeZZnce of the PAD Tfart^ h T Th?*" 1 , 9 r6S ,° UrCeS f ° S ° fUnCti ° nS 33 neCeSSary With ° Ut the fowardin 9 

performance ot the PAD. In fact, SCs can be allocated to external processors and PADs in an arbitrary manner in response to access traffic 
patterns. This design is more scalable than the traditional monolithic design since the response to traffic that ^ulr^K£^m^S 
processing is simply the installation of more and/or faster external processors. i ore service message 
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A.2 Programmable Access Device (PAD) 




Figure A.2 shows the detailed componente of the PAD. The PAD is a programmable access device with generic forwarding, marking policing and 
II filter functions. All these functions must be able to be configured or programmed by a SC through the MCRI. 

The Packet Header Filter operates on the DA, SA, TOS, SP, DP and other fields of a packet received from a user device and is configured by the 
control interface. It either directs a packet to a specific marker/policer, or else redirects the packet to the message interface The message 
interface may also inject a packet into the Packet Header Filter. 

The policer applies one or more token or leaky bucket algorithms to the stream of received packets to determine conformance to traffic ■ 
parameters established by the control interface. The results of the policing function can be discard of nonconforming packets, marking of 
nonconforming packets, or counting of nonconforming packets. 

The marker function sets the bits in the DiffSerwTOS byte, and/or the 3-bit MPLS experimental field, and/or the 20-bit MPLS label field and/or 
other fields for a specific flow as configured by the control interface. 

The Usage monitor tracks the statistics of different layer-2 and layer-3 traffic types. Thresholds and other criteria can be set up to invoke a 
reporting event. The reporting messages sent to the SC may summarize the usage information for a customer, report the occurrence of a high- 
priority traffic flow or warn the large volume of out-of-band traffic etc. 

Output buffers can be a single large buffer or distributed multiple buffers. A percentage of the total buffer or a fixed amount of buffer can be 
assigned to a class of traffic or a traffic flow classified by DA, SA, TOS, PT, SP and DP. Packet scheduler applies Weighted Round robin and 
other algorithms to support statistical multiplexing. The combination of the buffering mechanism and scheduling mechanism can put a limit on the 
queuing delay to transmit a packet over the PAD. 

The Shaper discards the nonconforming packets, sends marked packets to appropriate queues, and controls the delay jitter of a flow. 

Forwarding table keeps entries for each forwarding path. A forwarding path is represented by the packet flow attributes, i.e. DA, SA, TOS, PT, 
SP, DP, the incoming port and the corresponding output port. 
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(Hgure A.3 External Processor) 

Figure A.3 illustrates the logical elements within the External Processor. The External Processor is composed of several control and process 
functions that are utilized by policy servers and PADs to determine and affect the appropriate processing of packets and messages to and from 



PADs send messages, report information and control commands to the External Processor through the Message Control & Reporting Interface 
(MCRI). The Message Processor, Reporting Processor and PAD Controller utilize the MCRI. 

The Reporting Processor and Message Processor parse messages from PADs and notify the SC of the semantics of the messages. The 
difference between them is that the Reporting Processor processes only the reporting messages and the Message Processor processes all the 
other messages. The Report Processor is able to configure the reporting functions of the PAD including the type of reporting message, the 
content in the reporting message, whether to pass or not pass report information, etc. The Message Processor is able to configure the' IP filter to 
pass or not pass specific messages based on SA, DA, PT, SP, DP and/or other fields. 

The PAD controller configures and manages the PAD. The PAD Controller operates on the PAD Forwarding table, IP filter Usage Monitor 
Marker/Policer/Shaper, Buffer and Scheduler by commands or scripts. 

The Signaling Controller supports signaling protocols (e.g. RSVP, LDP, PNNI, FR UNI, ATM UNI, etc.) to set-up or tear down a VC or LSP across 
the network. The VC or LSP may have QoS specification with it. 

The Service Controller (SC) is the main control module for each service. It translates the messages from the Message Processor and Reporting 
Processor into appropriate policy queries and sends them to the PDP. It launches VC or LSP setups across the network through the Signaling 
Controller. It configures forwarding table, IP filter, Marker/Policer, Shaper, buffer and scheduler on a PAD by the PAD controller. All these working 
together delivers the desired service for the customer traffic. The service controller should have a table recording all the active sessions. Each 
PAD has at least a primary and secondary SC. If a PAD loses contact with the primary SC contact will be initiated with the secondary SC. The 
PAD will report state information to the secondary SC. Therefore, no synchronization is required between the SCs. 

To reduce the number of messages passed between a SC and the PDP, SCs are required to cache the frequently used policy lookups in its 
policy caches. For an incoming policy query, a SC looks up its policy caches first before it sends the query to the PDP. When a SC directly 
queries the PDP for a new service request, the SC may also request the PDP to dump all the related policy information from the policy database 
to its policy caches. Caching enables subsequent policy queries to utilize information that has already been retrieved recently from the policy 
server and reduce the message traffic between the SC and PDP. However there is a tradeoff between the number of direct policy queries and 
the cache refresh frequency and the amount of policy information downloaded from the PDP at each refresh. The objective would be to cache the 
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policies for IP services requiring intensive policy queries, such as SIP calls. There would be no need to cache the policy lookups for a TCP 
session that issues only one policy query in its lifetime. 

The PDP within a policy database interacts with a SC by utilizing the Service Policy Interface (SPI). With the SPI, a SC is able to use COPS 
LDAP and other policy query protocols to query the PDP within the policy database. The policy database resides on a policy server which would 
be an external processor resident on hardware separate from the External Controller and placed in different locations within the network. The SC 
sends policy requests to the PDP. The PDP returns the policy decisions for each request. The policy decision can be "approve", "reject" or 
configuration parameters for the SC and PAD. The PDP maintains usage information used by policy decision. For example, as a customer 
reserves bandwidth, the PDP needs to track the amount of bandwidth reserved by the customer and approve or reject a new service request by 
comparing the amount of remaining bandwidth allowed and the amount of bandwidth needed by the new service. 

With open SPI and MCRI, the carrier administrator should have the full control of the SCs and programmable access devices by writing scripts or 
configuring parameters. Customers could also be granted limited control over the SCs and PADs in support of self-provisioning. 
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PDP to SC 
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Set Inactivity Timer 

Approve the transaction 

Reject the transaction with a cause indication 

Return parameters in response of request 

Dump the policy lookups into SC policy caches 



Translate Signaling Messages into appropriate Policy Queries ( 

Query Policy Requirements 

Set the flag for caching of Policy lookups 

:e Policy Decisions into appropriate control commands 



A.4.2 Message, Control and Reporting Interface (MCRI) 



.g. RSVP -> COPS (RSVP), SIP-> COPS (SIP) 



PAD to External Processor 

• Message Passing 

Pass based upon SA, DA, PT, SP, DP, and/or other fields such as TCP Flags (SYN, ACK, RST, FIN, ...) 

• Reporting 

TCP Retransmit Threshold Crossed 
Inactivity Timer Expired 
Activity Detected 
Keepalive/Heartbeat Exchange 
State synchronization in event of SC switchover 



External Processor to PAD 



Inject packets into the user of trunk side interface 

Set pass/no pass flag based upon SA, DA, PT, SP, DP, and/or other fields 



Configure IP Filter 
Configure Marking 
Configure Policing 

Configure Output buffers & Scheduler 
Configure Shaper 

Drop multicast packets from a source 
Admit/Deny Source Routing Option 
Set TCP Retransmit Reporting Threshold 
Set Inactivity Timer 
Set Activity Timer and Level 
Configure Forwarding Table 
Set Traffic Reporting Threshold 

Allocate Resource (Bandwidth, Queue & CPU time) to a customer, a flow, a route or a multicast tree 
Set Reporting Flags (True/False) 
Set SVC, PVC or LSP 

A.4.3 PAD-SC Switchover Operation 

To prevent the interruption of the service, the PAD will switch to a backup SC in the event of a fault in the primary SC or the loss of connectivity 
to the primary SC. The PAD uses a reliable communication protocol (e.g. TCP session) to exchange information with SCs The KeepAlive 
message is exchanged between the PAD and a SC periodically to keep the TCP session active. When the KeepAlive message timeouts the 
PAD detects the failure of the SC. The PAD starts setting up a new TCP session with the secondary SC. If the PAD could not connect with the 
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secondary SC, the PAD would stop accepting new sessions and keep the state and the service for all the active sessions. After the TCP session 
between the PAD and the secondary SC is established, the PAD starts uploading the state information of all the active sessions controlled by the 
failed SC to the secondary SC. The PAD is required to keep the state machine for each active session. (See Figure A.4 The PAD successfully 
switches from the primary SC to the secondary SC after detecting the failure of the primary SC) 



PAD-SC Switchover Due to the Failure of the Primary SC 



2. KeepAlive timeout 




(Figure A.4 The PAD successfully switches from the primary SC to the secondary SC after detecting the failure of the primary SC) 

The communication between the PAD and secondary SC may remain in a non-revertible mode, or may revert to the primary SC in a revertible 
mode to maintain load balancing of SC processing across the distributed PADs. Reversion to the primary SC may be accomplished with no 
service interruption as follows. When the primary SC begins working again, it sends TCP session set up message to the PAD. The PAD 
handshakes with the SC and recognizes that it is the primary SC. The PAD uploads all the active sessions to the primary SC. After the uploading 
is successfully completed, the PAD notifies the secondary SC that the primary SC is up and closes its TCP connection with the secondary SC. 
When the secondary SC gets the notice from the PAD that the primary SC is up, it closes the TCP connection with the PAD and deletes all the 
related state information. (See Figure A.5) 
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PAD-SC Switchover after Primary-SC is Restored 

Primary SC PAD Secondary SC 



2. SYN. ACK 



(Figure A.5 PAD Restores Connection with Primary SC)" 
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A.5 Examples 

Several examples are provided below to illustrate how various network activities may be supported by the components of the proposed invention. 
Generic space-time drawings are used to illustrate the sequence of messages as they are passed between the various components of the PAD, SC 
and network. The following terms are used frequently in the space-time drawings: 

Customer Site- Represents the point at which a device or application (typically at an end-user location) where service is desired. The customer 
application may be requesting, for example, network resources (e.g. RSVP) or to participate in a private broadcast (e.g. multicast). 

PAD- The Programmable Access Device as described is section A.2. 

POP- The Policy Decision Point is a logical point that resides within the policy server. Messages to and from the PDP are carried by the Service 
Policy Interface as described in sections A.3 and A.4.1. 

Network- The network line in the drawings represents routers or switches within the service provider network that would that send a message or 
packet to an egress point or corresponding system at another access point on the network. The far end network system would process the request or 
packet being sent by the Customer Site or PAD. 

The following examples are provided in the sections that follow; 

Network-Level Signaling Example 
RSVP Signaling Example 

Connection-Oriented Transport Examples Using TCP Sessions 

TCP State Machine on the PAD 
» TCP Session Establishment 
» TCP Session Close 

TCP Session Unauthorized 

TCP Session Timeout 

TCP Session Abrupt Close 

Connectionless Transport Examples Using UDP Reporting Function 

■ UDP Reporting Successful 

0 UDP Reporting Unauthorized 

■ UDP Reporting Timeout 

Application-Level Examples Using SIP Signaling 
SIP Call Establishment 
SIP Call Termination 
SIP Call Timeout 
SIP Call Negotiation 

IP Multicast Examples 

Authorized Registration of a New Multicast Group 
» Unauthorized Registration of a New Multicast Group 

Authorized Membership Query 

Unauthorized Membership Query 

Authorized Sending of Multicast Packets 
» Unauthorized Sending of Multicast Packets 

■ Receiving Authorized Multicast Packets 
Receiving Unauthorized Multicast Packets 
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A. 5.1 Network-level Signaling Example 

In the example shown in Figure A.6, the customer application initiates an RSVP PATH message (1). The PAD forwards the PATH (2) message to 
the SC, which is called a Reserved Bandwidth Service Controller (RBSC) in this example. The RBSC queries the PDP (3). The PDP approves 
the RBS to the customer (4). The RBSC returns PATH (5) to PAD. PAD sends the PATH (6) message downstream to the other end of the 
network. The receiver responds by a reservation (RESV) message (7). The PAD passes the RESV (8) to the RBSC, which invokes another policy 
query (9), The PDP approves and records the bandwidth requirements by the RESV (10). (Here we assume that the PDP keeps track of the 
allocated bandwidth for a customer. The occupied bandwidth is compared with the committed bandwidth to a customer for policy-based 
admission decision.) The RBSC then kicks off either the ATM signaling or the MPLS signaling to set up a SVC or a LSP (1 1 ). After the 
connection is confirmed (12), the RBSC configures the PAD'S IP filter and forwarding table to transmit packets of this flow over the established 
SVC or LSP (13). The RBSC in turn returns RESV (14) to the PAD. The PAD sends the RESV (15) upstream to the sender application. The 
RBSC also sends the CONFIRM downstream to the receiver (17) to finish the handshake for setting the SVC or the LSP. In this example the IP 
filter in PAD captures RSVP messages according to its protocol type (PT=46). 
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A. 5. 2 Connection-oriented transport examples using TCP 
• TCP State Machine on the PAD 



TCP STATE MACHINE Service 
Controller 




(Figure A.7 TCP State Machine) 
The TCP state machine on the PAD has two states: idle and active. The state transition is described below. 
IDLE -> ACTIVE 

1 . When the state machine is in the idle state (non-existing TCP session), it passes and only passes the first SYN message received from the 
^ I ^ ™ ( a) ' he SC queries the policy selver for poli °y dec ' si °ns for this TCP session after it receives the SYN message from the 
PAD. if the TCP session is approved, the SC returns the SYN message back to the PAD (1 .b). The PAD changes the state machine to the 
active state and forwards the SYN message to the receiver to complete the three-way handshake (1 .c, 1 .d). The PAD passes the ACK 
message representing the success of the handshake to the SC (1 .e). The SC knows the TCP session is open and adds the TCP session 
mto its active session table. The SC updates the PAD with an inactive timer and other related parameters of this TCP session and then 
sends the ACK back to the PAD (1 .f). The TCP session is ready for data transmission (1 .g). 

ACTIVE->IDLE 

2. When the PAD receives a FIN message from the either side of a TCP connection for an active TCP session it resets the TCP state 
machine to be idle (2.a). The PAD passes the FIN message to the SC (2.b). The SC learns that the TCP connection is inactive and deletes 
the TCP session from its active session table. The PAD forwards the FIN message to its destination to complete the three-way handshake 
for closing the TCP connection (2.c, 2.d). The PAD deletes the state machine of the TCP session 

3. When the inactive timer on the PAD for an active TCP session expires, the PAD resets the TCP session to be idle (3 a) The PAD reports 
the timeout error to the SC (3.b). The SC deletes the TCP session form its active session table and updates the PAD. The PAD deletes the 
state machine of the TCP session. 

4. When the PAD receives a RST segment from either side of a TCP connection, it knows that an abrupt close is requested and resets the 
TCP session to be idle (3.a). The PAD reports the timeout error to the SC (3.b). The SC deletes the TCP session from its active session 
table and updates the PAD. The PAD deletes the state machine of the TCP session 
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aSS ZVHt L^dpm 3 ^ TCP SYN J n ? essa 9 es for "on-existing TCP sessions to them. In the example shown in Figure A.8, The client 
nt!t TPP ' , ? , EN i1) command that tel,s TCP *hat it wants to open a connection to a server at a given port and IP address The 
chent TCP picks an initial sequence number (800 in this example). The client TCP sends a synchronize segment (SYN) carrying this 
sequence number (2). When the SYN arrives, the PAD detects that it is a mission-critical e-commerce TCP session based w the 
rcTrxZ f a f h dreSi ; anCl P H 0rt ? umber < PT=6 ' PORT=80). The PAD passes the SYN to the e-commerce service controller (ECSC) (3). The 

TCP k t£ TTlvJ! k 0 ' f r ° m th6 PDP (4) USing LDAP ° r $0me 0ther P° lic y P rotoco1 - Tne PDP approves the 

TCP session (5). The ECSC sends the SYN back to the PAD (6). When the PAD receives the SYN from the ECSC it spawns a new TCP 
state machine and sets it to an active state (7). The PAD sends the SYN downstream to the server (7) When the SYN arrives the server 

In ACK of fiflimf L S l qU T t t "Tf ( ^°, in u hiS C3Se) ' ThB SerVW TCP SendS a SYN segment containin 9 initial se ^ ence "umber 400 and 
™™ 1(8 i meaning that the first data byte sent by the client should be numbered 801 . The SYN/ACK message is sent back to the 

fi st tSl'^Vn^T P reC K iV l S Se T' S SYN/ACK meSSage ' the client TCP returns an ACK of 401 w hi<* means that the 

hlnll V 6 S f T er J h ° Ul l be numbered 401 • The p AD Passes the ACK to the ECSC (1 1 ). The ECSC learns that the three- 
Sad fl ? t 5,? >Z°Tf l a T ^ TCP S6SSi ° n iS ° Pen ' The ECSC 3ddS th6 TCP SeSsion int0 its active s « ssion ta We and configures 
hf c top ( 1 ' the h . n r b6r -f r f,! ransm,ssl0ns and inactive timer. The ECSC also sets the marker to mark the packets belonging to 
TCP seLlonfthfqrf T Y ' fuVo^u a e plications ' such as ,he ™>™V applications that will only aHow the teacher to disconnect the 
l.ndttt ?™ t ^ a f 6 ' P f«" f !° ' 9n ° re the Client F,N -> The ECSC tf1en retums 'he ACK segment to the PAD (13). The PAD 

sends the ACK to th* d^hnat,™ «««r (14) . The client TCP notifies its upper layer application that the connection is open (15) The client 



sends the ACK to the destination 
and the server start exchanging data in the TCP 



•n (16). 
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(Figure A.8 TCP Session Establishment Example) 
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TCP Session Close 

Either side of a TCP connection can launch a close. The server initiates the close in the example shown in Figure A 9 The server 
application has finished its work and tells TCP to close the connection (1). The server TCP sends a FIN segment (2), informing the partner 
that it will send no more data. The PAD resets the state machine of the TCP connection to be idle and passes the FIN segment to the ECSC 

(3) . The ECSC deletes the TCP session from its active session table and configures the PAD to stop marking packets for this TCP session 

(4) . The PAD forwards the FIN segment to the client (5). The client TCP acknowledges receipt of the FIN segment (6 7). The client TCP 
notifies its application that the client wishes to close. The client application tells its TCP to close. The client TCP sends a FIN message to 
the server TCP (8,9). The server TCP receives the client's FIN and responds with an ACK to the client (10). The PAD knows the three-way 
handshake for closing the TCP session is successful and deletes the state machine of this TCP session. The PAD then forwards the ACK to 
the client (11). The server TCP notifies its application that the connection is closed (1 3). 
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(Figure A.9 TCP Session Close Example) 
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• TCP Session Unauthorized 

In the example shown in Figure A.10, the client application issues an OPEN (1) command that tells TCP that it wants to open a connection 
to a server at a given port and IP address. The client TCP picks an initial sequence number. The client TCP sends a synchronize seqment 
(SYN) carrying this sequence number (2). When the SYN segment arrives, the PAD detects that it is a mission-critical e-commerce TCP 
session based on the destination IP address and port number (PT=6, PORT=80). The PAD passes the SYN segment to the ECSC (3) The 
ECSC asks for the policy and admission control from the PDP (4) by LDAP. The POP denies the TCP session either because there is not 
enough resources in the network or because the client has not ordered the e-commerce service (5). The ECSC in turn issues a reset 
segment to the PAD (6). The PAD sends the RST segment upstream to the client TCP (7). When the client TCP receives the RST the client 
TCP aborts the session. (Note: Since the PAD does not receive a SYN segment from the ECSC, no state machine has been created for the 
TOP session in this example.) 
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(Figure A.10 TCP SessioTTunauthorized Example)" 
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• TCP Session Timeout 

Normally, TCP sessions have a proper disconnect. However, in the event a server fails or reboots or the network breaks the TCP session 
is going to timeout in the host. In this case, normal disconnect will not occur. Other means must be used to update the ECSC to the inactive 
state for this session. In the example shown in Figure A. 11, the route to the TCP partner is disrupted by loss of a link or a node (1 ). The 
client TCP starts re-transmitting the same data. After reaching a threshold number of retransmissions (2,3,4), the client TCP timeouts and 
aborts the connection (5). Subsequently, the inactive timer in the PAD expires. The PAD updates the TCP session to an inactive state and 
reports the TCP session timeout error to the ECSC (7). The ECSC deletes the TCP session from its active session table and configures the 
PAD to stop marking the packets for the TCP session. The PAD deletes the state machine of the TCP session 
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TCP Session Abrupt Close 

Either side of a TCP connection can launch an abrupt close. This may be done because the application wishes to abort the connection or 
because TCP has detected a serious communication problem that can not be resolved. An abrupt close is signaled by sending a RST ' 
segment to the partner. The seiver initiates the abrupt close in the example shown in Figure A.12 (1 ,2). The PAD resets the state machine 
tor the TCP session to be idle and passes the RST segment to the ECSC (3). The ECSC deletes the TCP session from its active session 
table and configures the PAD to stop marking packets for this TCP session (4). The PAD deletes the state machine of the TCP 
forwards the RST segment to the client (5). The client closes the TCP session upon receiving the RST segment (6) 



TCP Session Abrupt Close Example 
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TFigTjreA.12 TCP SessionAbrupt Close Examplef 
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A.5.3 Connection-less transport examples using UDP reporting function with specific port number ranges 
UDP Reporting Successful 

Section A.5.1 gives an example of RSVP signaling where the customer initiates the RSVP messaging. In the example shown below in 
Figure A.13, the client computer in the customer site does not support RSVP. A user on the customer site invokes a client program to make 
an IP telephone call. The client process gets an unused UDP port from the pool of available ports assigned for voice data transmission The 
client application starts sending voice data encapsulated by UDP packets over the network as best-effort traffic (1). The PAD detects the 
constant AcwofUDP packets (PT=17) within the voice port range and reports the occurrence of voice data flow to the IP Telephony Service 
Controller (IPTELSC) (2). The IPTELSC queries the PDP for policy decision (3) using COPS or some other policy query protocol The PDP 
inds that the customer ordered guaranteed service for his IPTEL calls and commands the IPTELSC to provide guaranteed service for this 
II TEL session (4). The IPTELSC configures the PAD with an inactive timer for this IPTEL call and instructs the PAD to stop reporting the 
occurrence of this IPTEL session. The IPTELSC initiates a reserved bandwidth route setup process (6-16). For an ATM core a bi-directional 
SVC is set up. For an MPLS core, two uni-directional LSPs are set up. After the QoS path is established, all the voice UDP packets 
belonging to the IPTEL session are transmitted through the same QoS path (17). The PAD will periodically generate RSVP refresh 
messages on behalf of the user. If the IPTELSC caches enough policy information on makingadmission control decision in the first search 
(3,4), the IPTELSC does not need to query PDP for the second time and 10,1 1 are optional. 
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(Figure A.13 UDP Reporting Successful Example) 
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UDP Reporting Unauthorized rd 9 e 20 OT 3 ' 

customers IPTEL calls and sends only information response back to the IPTELSC (4) The IPTELSC rnnfln,^»« thl pan f ,1 
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UDP Reporting Timeout 

Ir feih!?r n Mh!!TnH aCtiVe ! m9r , ex £! ,y C3n be caused either b V normal completion of the UDP data flow, the break of the transmission links 



UDP Reporting Timeout Example 
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(Figure A. 15 UDP Reporting Timeout Example!" 
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~ =KT ( S ' 9n f r S l, ? required t0 paSS almost every SIP messa 9es to the SC because each SIP message may request a different 
capability set for the SIP call. Therefore, each SIP message invokes a policy query to approve a capability set. To reduce the number of 
messages exchanged between the SC and the PDP, the SC requests the PDP to dump the policy lookups for the SIP requester into its 
policy caches in its first policy query for a SIP call. The SC then uses the cached policies to make decisions for the SIP messages The SIP 
state machine resides on the PAD. Thus the PAD is able to decide whether it needs tc ' • - - - 



s the received SIP 



to the SC and 



should try to avoid forwarding SIP messages to the SC whenever possible. 
SIP Call Establishment 

In the example shown in Figure A.16, a caller on a customer site issues a SIP INVITE request to the callee (1). When the PAD detects the 

Co^rVrVA^ th rr^ DP > n t T P f ran9e th3t iS aSSi9n6d t0 S ' P) ' " paSS6S the INVITE rec > uest t0 the Conference Call Service 
controller (CCSC) (2). The CCSC sets the policy dump flag and queries the PDP for policy decisions using LDAP or some other oolicv 
^ 'S r ?} oc °l { H ™ e PDP approves the SIP session (4) and dumps the policy lookups for the SIP caller into the policy caches of the 
£ m« ^ onn IT* He INV £ E reqU6St *° the PAD (5) ' The PAD fo ™ ards the INVITE re « uest to th « C£ »"ee (6). The callee responds 
° h 03 , ^ 20 ° ° K messa 3 6 (D- Since there is no change in the SIP capability set the PAD forwards the SIP 200 OK message directly 
to the caller (8) and does not pass it to the CCSC. The caller acknowledges the acceptance of the 200 OK message via an ACK request (9) 
Li? rl r^f 2? l CK o^ qUeStfo the CCSC (10) ' The CCSC queries its polic y caches and a PP rwes the capability set of the SIP 
S nit! tho 1% ™ ^ S t^l° n ,nt ° itS aCtiVe SeSSi0n table and confi 9 ures ths PAD ^th an inactive timer and other parameters to 
facilitate the SIP call (11). The ACK «s sent back to the PAD (12). The PAD in turn sends the ACK to the callee (13) 
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(Figure A.16 SIP Call Establishment Example) 
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SIP Call Termination i-«y« ^ ui J / 

In a multi-party SIP conference call, each party can only drop himself from the call. After the last party leaves the call the call is terminated 

However, ,n a two-party S! P call, either the cal.er or the callee can terminate the call. Figure A.17 show a Zc Tpa^ caSlSna ton 

CCSC % T rtetckc ° h me , r ,p te Si9nal r ^ ^ teM ° n by Se " din9 3 BYE r6qUeSt < 1 >" The PAD P ass ^ ^ By" request to the 

l^i ^ , ? d '! teS hS S ' P SeSSI ° n fr0m ,ts active session ^ and cleans its P 0| i°y caches. The CCSC then updates PAD to 
de ete the entire configuration for the SIP call (3). The CCSC also prevents the PAD from passing subsequent SIP messaaes from The S P 
can. The CCSC sends the BYE message back to the PAD (4). The PAD forwards the BYE "messag to the ca S (sT The^ Slle 
ShTccsf m 6 ° f S ' P 03,1 V " 3 SIP 200 ° K m6SSa9e (6) - The PA ° f0W3rdS the 200 ™2^S2l^5Sut passing it 
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(Figure A.17 SIP Call Termination Example) 
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S-^P-S in the examp.e shown in Figure A 18 1 the callee 

The PAD passes the BYE requ^HoteCC^ " 3 J^SSc Ine^f™ ^ ^ ^ ^ 3 ^-2^ 

pohcy caches. The CCSC commands the PAD to delete the entiJ SI,m?™? '* S a ° tiVe S6SSion table and clea ^ its 
from passing it subsequent SIP messages from the J P can The h^ Rvl Ca " W The CCSC a,S0 P revents PAD 

est to the cal.er (6). The caller acknowledges ^ eTof ^ip^ 0 TI^^ m PA ° (5} ' The PAD fof « 
sssage to the callee (8). * K session Vla a Slp 200 OK message (7). The PAD forwards 



BYEreq 

the OK message to the callee (8). 
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(2) In the example shown in Figure A.18.2, all parties of the SIP call die. The inactive timer of the SIP caSres (1? The PAD reports the 
fcmeout error to the CCSC (2). The CCSC deletes the SIP session from its active session table and cleans its policy Sches The 
CCSC commands the PAD to delete the entire configuration for the SIP call (3). 
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(Figure A.18.2 SIP Timeout Example (2)— All parties in the SIP call die and timeout is detected tr 
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• SIP call negotiation 



SIP Call Negotiation Example 
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iFigure A.19 SIP Call Negotiation Example) 
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A.5.5 IP Multicast Examples 

can jom or leave a multicast group at will. There is no needTo ^te^^^ ^T^JT^ paCkets ' Multicast 9™P members 
However for a multicast service, the customers expect control Z ^nlaenZ lTZ 9 k T * ""^ 9 rou P management entity 
senders it , S important that only authorized sources ^S^m^^TnL^ membe .^ hi P for the sender and receiver. For 

The proposed access system architecture in this petition enabies po.icy-based multicast service moment by monitor ing the IGMP 



Manage the registration of the new multicast groups 



(1 ) Authorized Registration of a new multicast group 
[ont^ 

group Report message to the Multicast 'service Co nSffsS TheSr 'ono ° n ^ The PAD f « «*> JO- 

or some other policy query protocol (3). The POP finds the seSer s IP addrS ?n fh , k, ° P W ' thin the p0licy database wit " LDAP 
sender join the group (4). The Membership Report m^qffe ^Sert K 1 f , membershi P ,ist and W^ves that the 
member of that group on the network the router ad* ffhf Z f ° Warded to the ed 9 e rout er (5,6). In case the sender is the first 
network on which the sender Sached (7? 9 P 9 reP ° rted { ° " le ' iSt ° f multicast ^ memberships onThe 



(1) 



Authorized Registration of a New Multicast Group 



(FigTjreX20.1 Authorlie¥Reiiit5aol^f5" 



w multicast group Example) 



(2> ln n th Uth ° riZed | Registration of a new multicast group 

(on ^mS^SSS!:^ TetTrlT™0 S^me^m?^^ m6SSage t0 the «*» router (1 ) 

jom-group Report message to the Multicast Service Co JXYcHMSC) The MSP nn ^ °" PT=Z The PAD forwafds »>V 

or s °™ other policy query protocol (3). The W^&m^^teS^^ ^ M the polic * database witn 
jom-group request (4). The MSC drops the join-group Report mesfaae and w L ?nt^ ? IT ^ ™' tiCaSt grou P and re i ects 
prevents the unauthorized host from registering a new grou * Tthe edge route ^ '° 9 3 Wamin9 m6SSa9e ^ This 
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Unauthorized Registration of a New Multicast Group 












(Figure A.20.2 Unauthorized Registration of a 



m multicast group Example) 



Manage the host membership queries 
(1) Authorized Membership Query 

n»!!lLTT e f h °T in fi 3. ur ^ A - 21 the PAD receives a " l( 3^P host membership Query message from the edge router (1 ) It 
omto^l % it php ?. ^ m6$Sa9e t0 MSC (2> ' ThS MSC qUeri6S the PDP wifh LDAP or some other PO"^ iery 
1 1^' inL ^Pl^i th . 6 f UrCe , ad * e i S for thiS « iS the authOTized ^ router and PDP approves the Query (4). The host 
is in the customer site/sub-network (5,6). 



membership Query message is forwarded to the h( 



Authorized Membership Query 



(A.21.1 Authorized Membership Query Example) 



Unauthorized Membership Query 

In the example shown in figure A.21 .2, the PAD receives an IGMP host membership Query message (1). It passes the host 
^™kersh'p Query message to the MSG (2). The MSC queries the PDP with LDAP or some other policy query protocol (3). The PDP 

e and rejects the Query (4). The MSC drops the Query message and 



finds that the Query is from an unidentified or unauthorized s< 
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Unauthorized Membership Query 




(A.21.2 Unauthorized Membership Query Example) 
Manage the sending of multicast packets to the network 
(1 ) Authorized sending of multicast packets to the network 

'"^fr? f°T in f ' 9ure , A ; 2 , 2 - 1 ' a host on a customer site sends IP multicast packets to the multicast groups When the PAD 
h f^c ™ th T^ aSt PaCk f h ' (1 2^ 6 ' P f " ter CaptUr6S the paCket b * checkin S its ™ iticast address. The PAD passes ?he packet to 
he MSC 2). The MSC queues the POP with LDAP or some other policy query protocol (3). The PDP finds that the Source address of 
the IP multicast packet is authorized for sending multicast packets to the multicast group and approves the send inq oHhe mZast 

7 m f ? nfl ? f UreS / h6 1™ '° dir6Ctly f0rWard multicast P ackete to the e i « r me soured *mul«it pair 
£EK Th r t, mUlt '5; aSt f CkSf t0 the PA ° (6) ' The PAD forwards the multicast P actet to the edge router (7) The PDP P 
forwards all the following multicast packets for the flow directly to the edge router without passing to the MSC (8 9) 



Authorized Sending of Multicast Packets 



(Figure A.22.1 Authorized sending of multicast packets Example) 
(2) Unauthorized sending of multicast packets to the network 

In the example shown in figure A.22.2, a host sends IP multicast packets to the multicast groups. When the PAD receives the first 

Th"! MQo Pa ( i' 1 fi '^ r , C ^ t " reS the Pa0ket by checkina its multicast address ' The PAD P^ses the packet to the MSC (2) 
_The MSC queries the PDP wtth LDAP or some other policy query protocol (3). The PDP finds that the source sending the multicast 
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^^.M^^^Z! 1 ^^^!^ an l rejSCtS the sending of multi °ast packets to the network (4) P Th 9 e^SC 0 c f onfigures the PAD tc 



drop multicast packets for the (source, multicast address) pair and writes a warning message into the e< 
the rfemai nf QPn/i ce attack by flooding multicast packets onto the network. 



it log (5,6,7), This prevents 



Unauthorized Sending of Multicast Packets 




(Figure A.22lfUnauthorized sending of multicast packetsExampie) 
Manage the receiving of multicast packets from the network 
(1 ) Receiving authorized multicast packets 

Wh»n I a pfn $h0Wn in l 9 T t 2 V- the 8dge r0Utel ' recelves IP multicast P ackets from the ™twork and forwards them to the PAD 
When the PAD receives the first multicast packet from the edge router (1), the PAD passes the packet to the MSG (2) The MSC 
quenes the PDF w,th LDAP or some other policy query protocol (3). The POP finds that the source add^of fte IP muScasf packet 
was authorized for sending multicast packets to the multicast group and approves forwarding the multicast packet to mute hosts in 
add^lr S? (4) . T T MS f h C °r nf T T- PA ° t0 dire0t,y " t0 the edge router <™<« cast P-Kets for the souS mulSst 
?e custome L£ m Tn^PAnl^* T'lfJ f ^ t0 the PA ° < 6) ' The PAD fowardS the multicast P actet to the ™'«<^t hosts in 
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Receiving Authorized Multicast Packets 



(A.23.1 Receiving Authorized Multicast Packets Example) 
(2) Receiving unauthorized multicast packets 

In the example shown in figure A.23.2, the edge router receives IP multicast packets from the network and forwards them to the PAD 
When the PAD receives the first multicast packet from the edge router (1), the PAD passes the packet to the MSC (2) The MSC 
queries the PDP with LDAP or some other policy query protocol (3). The PAP finds that the source sending the multicast packets is 
unidentified or not authorized and rejects forwarding the multicast packet to the multicast hosts in the customer site (4) The MSC 
configures the PAD to drop multicast packets for the (source, multicast address) pair and write a warning message into the event log 
(5,6,7). This prevents the unauthorized multicast packets from flooding the sub-network in the customer site 



Receiving Unauthorized Multicast Packets 
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t 5 Update PAD 
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ACRONYMS 



ACK 


Acknowledgement 


API 


Application Programming Interface 


ATM 


Asynchronous Transfer Mode 


BGP 


Border Gateway Protocol 


CCSC 


Conference Call Service Controller 


COPS 


Common Open Policy Service 


CPE 


Customer Premise Equipment 


CPU 


Central Processor Unit 


DA 


Destination Address 


Diffserv 


Differentiated Services 


DP 


Destination Port Number 


DSCP 


Diffserv Codepoint 


ECSC 


E-Commerce Service Controller 


FAST 


First ATM SVC Trial 


FIN 


Finished 


FR 


Frame Relay 


IGMP 


Internet Group Multicast Protocol 


IGP 


Interior Gateway Protocol 


IP 


Internet Protocol 


IPTEL 


IP Telephony 


IPTELSC 


IP Telephony Service Controller 


LDAP 


Lightweight Directory Access Protocol 


LDP 


Label Distribution Protocol 


LPC 


Linear Predictive Coding 


LSP 


Label Switched Path 


MCIW 


MCI WorldCom 


MCRI 


Message, Control, and Reporting Interface 


MPLS 


Multiprotocol Label Switching 


MSG 


Multicast Service Controller 


PAD 


Programmable Access Device 


PADC 


Programmable Access Device Controller 


PANDSC 


Programmable Access Device with Distributed Service Control 


PDP 


Policy Decision Point 


PNNI 


Private Network-Network Interface 


POP 


Point of Presence 


PT 


Protocol Type 


PVC 


Permanent Virtual Connection 


QoS 


Quality of Service 


RBS 


Reserved Bandwidth Service 


RBSC 


Reserved Bandwidth Service Controller 
Reset 


RST 


RSVP 


Resource Reservation Protocol 


RTP 


Real-time Transport Protocol 


SA 


Source Address 




Subnet Bandwidth Manager 


SC 


Service Controller 


SIP 


Session Initiation Protocol 


SLA 


Service Level Agreement 


SP 


Source Port Number 


SPI 


Service Policy Interface 


SVC 


Switched Virtual Connection 


SYN 


Synchronizing segment 


TCP 


Transmission Control Protocol 


TDM 


Time-Division Multiplexing 


TOS 


Type of Service 


UDP 


User Datagram Protocol 


UNI 


User Network Interface 


WAP 


Wireless Application Protocol 
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From: Lei Yao [lei.yao@wcom.com] 

Sent: Thursday, October 05, 2000 10:06 AM 

To: 'Brian F. Russell' 

Cc: 'Dave.mcdysan'; 'stevenmccann'; lee.thomas@wcom.com; jim.dalton@wcom.com 

Subject: RE: patent application 



Attached please find our consolidated comments. We divided the comments into general 
comments and detailed comments. The general comments are put into a separate document. 
Detailed comments are made in the draft document with our initials. We also made some 
changes in the drawings . 

Below is the conference bridge info. : 
Date: 10/10 

Time: 10:00 - 12:00 (EDT) 
Toll Free - 888-455-9652 
Pass Code 25 62 



Thanks again for your excellent work. 
Lei 



Original Message 

Prom: Brian F. Russell [mailto:brussell@patentlawyers.com] 
Sent: Tuesday, September 05, 2000 4:49 PM 
To : lei . yao 

Cc: Dave.mcdysan; Steven. mccann 
Subject; RE: patent application 

<< File: RICO0033 (44796) .doc » << File: landscapedrawings.doc » << File: 
portraitdrawings.doc >> Gentlemen, 

Please find attached an initial draft of the first patent application. I would appreciate 
it if you could forward a copy to Lee for his review, as I don't have his email address. 

I will continue working on the claims for the 3 additional applications while I await your 
comments. As you work through the document, please address the highlighted comments 
embedded in the text. Also, please consider whether the description is technically 
accurate and complete (whether it discloses to a person "skilled in the art" how to make 
and use the invention) and discloses the "best mode", if any, in which the invention may 
be used. 

It would be helpful to me if comments for all the inventors can be compiled into either a 
single marked up version of the application or a single set of separate comments. Thank 
you for your assistance in the preparation of this application, and please contact me if I 
can resolve any issues that arise during the review process. 

Best regards, 



Brian F. Russell 

Felsman, Bradley, Vaden, Gunter & Dillon, LLP 
Suite 350, Lakewood on the Park 
7600B N. Capital of Texas Hwy. 
Austin, TX 78731 



512.343.6116 (voice) 
512.343.6002 (fax) 
brussell@patentlawyers . com 
www. patentlawyers . com 

>>> Lei Yao <lei . yaoOwcom. com> 09/05/00 02; 33PM >>> 
Brian, 

Thanks for the update. We are looking forward to read the application. 
Lei 

Original Message 

From; Brian F. Russell [mailto:brussell@patentlawyers.com] 
Sent: Thursday, August 31, 2000 11:39 AM 
To ; lei . yao 

Cc: Dave . mcdysan ; Steven. mccann 
Subject; RE; patent application 

Lei, 

Just to update you on my progress on the applications, I have nearly completed a draft of 
the first application and expect to send you the draft for review next week. As we 
discussed, the all of the applications will contain the same basic description, but will 
differ in focus in the claims, summary and abstract. Hopefully, the commonality in the 
applications will facilitate your review. 

Best regards, 

Brian F. Russell 

Felsman, Bradley, Vaden, Gunter & Dillon, LLP 

Suite 350, Lakewood on the Park 

7600B N. Capital of Texas Hwy. 

Austin, TX 78731 

512.343.6116 (voice) 

512.343.6002 (fax) 

brussell@patentlawyers . com 

www . patentlawyers . com 
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Margo Livesay 



From: 



Brian F. Russell [brussell@patentlawyers.com] 
Thursday, October 26, 2000 11:15AM 
dave.mcdysan; lei.yao 
lee.thomas; Steven. mccann 
RE: patent application 



Sent: 

To: 

Cc: 



Subject: 



Gentlemen, 



Just to update you on the status of the patent applications, I have unfortunately been 
unable to work on the patent applications since I received the information Dave McDysan 
provided because of additional duties I have had to assume since Andrew, the firm's 
managing partner, broke his back last weekend. 

Originally, I had anticipated completing all of the applications by the end of the month. 
I now believe that I can have revised drafts of the applications to you for review by 
11/7/00 . 

I apologize for the delay. 
Best regards, 
Brian F. Russell 

Pelsman, Bradley, Vaden, Gunter & Dillon, LLP 

Suite 350, Lakewood on the Park 

7G00B N. Capital of Texas Hwy. 

Austin, TX 78731 

512.343.6116 (voice) 

512.343.6002 (fax) 

brussell@patentlawyers . com 

www . patentlawyers . com 
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From: 
Sent: 
To: 
Cc: 



Brian F. Russell [brussell@patentlawyers.com] 
Monday, November 06, 2000 11:35 PM 
dave.mcdysan; let.yao 
lee.thornas; steven.mccann 
RE: patent application RIC00043 



Subject: 



Follow Up Flag: 
Flag Status: 



Follow up 
Completed 




RIC00043.cla.doc 

Gentlemen, 

Attached please find the claims, abstract and summary for the external processor 
application. 

Best regards, 



Brian F. Russell 

Felsman, Bradley, Vaden, Gunter & Dillon, LLP 

Suite 350, Lakewood on the Park 

760 0B N. Capital of Texas Hwy. 

Austin, TX 78731 

512.343.6116 (voice) 

512.343.6002 (fax) 

brussell@patentlawyers . com 

www . patentlawyers . com 
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From: 



Brian F. Russell [brussell@patentlawyers.com] 
Monday, November 06, 2000 1 1 :40 AM 
dave.mcdysan; lei.yao 
lee.thomas; steven.mccann 
RE. patent application RIC00033 



Sent: 

To: 

Cc: 



Subject: 



Follow Up Flag: 
Flag Status: 



Follow up 
Completed 




landscapedrawings, Overview.ppt portraitdrawings.do RIC00033 
doc c (44796).doc 



RIC00042.cla.doc 



Gentlemen, 



Attached, please find attached the following: 

(1) the second draft of the patent application, which includes your most recent comments 
[Please see my imbedded notes and questions pertaining to the "Overview" description that 
was added] and a full claim set; 

(2) figures for the application (which are unchanged except for the insertion of reference 
numerals in the "Overview" drawings provided by Dave) ; 

(3) claims, abstract and summary for the second application covering the PAD (Docket No. 
RIC00042) . 

I will send the claims, abstract and summary for the other two applications either later 
today or tomorrow. 

Best regards, 

Brian F. Russell 

Pelsman, Bradley, Vaden, Gunter & Dillon, LLP 

Suite 35 0, Lakewood on the Park 

7600B N. Capital of Texas Hwy. 

Austin, TX 78731 

512.343.6116 (voice) 

512.343.6002 (fax) 

brussell@patentlawyers . com 

www . patentlawyers . com 
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Mar g o Livesay 



Prom: LEi YAO [lei.yao@wcom.com] 

Sent: Wednesday, November 08, 2000 2:27 PM 

To: 'Brian F. Russell'; dave.mcdysan 

Cc: lee.thomas; steven.mccann 

Subject: RE: patent application RIC00044 



Brian, 

Thanks for putting together all four applications during the short period. 
Steven, 

I will coordinate with Dave and Lee to review these applications. After the applications 
have been agreed on by us, do we need approval from you before we really submit these 
applications? What is the next step from the legal department? 

Thanks . 

Lei 

-Original Message 

From: Brian F. Russell [SMTP : brussell@patentlawyers . com] 

Sent: Wednesday, November 08, 2000 12:37 AM 

To : dave . tncdysan; lei . yao 

Cc: lee.thomas; steven.mccann 

Subject: RE: patent application RIC0O044 

<< File: RIC00044.cla.doc >> Gentlemen, 

Please find attached the claims for the final patent appliication covering the MCRI . 

Best regards , 

Brian F. Russell 

Felsman, Bradley, Vaden, Gunter & Dillon, LLP 

Suite 350, Lakewood on the Park 

7600B W. Capital of Texas Hwy . 

Austin, TX 78731 

S12.343.S116 (voice) 

512.343.6002 (fax) 

brussellOpatentlawyers . com 

www . patent lawyers . com 
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JViar goJL iy esay 



From: 
Sent: 
To: 
Cc: 



LEI YAO [tei.yao@wcom.com] 

Tuesday, November 21, 2000 7:11 PM 

"paul. roberts@wcom.com'; 'Steven.McCann@wcom.com' 

'dave.mcdysan@wcom.com'; 'brussell@fbvgd.com'; 'lee.thomas@wcom.com' 

patent applications 



Subject: 



(D 



patentcrnts.zip 



Paul, 



Attached please find the final comments we made for the patent applications prepared by 
Brian Russell. We understand that you will work on this case representing Steven. The 
applications were well written. We only made several minor changes. If you turn on "track 
change" options of MS Words, you should be able to see those changes. We believe that the 
applications are ready to be submitted. Since there is going to have a patent law change 
on 11/29, which may bring negative impacts on pending patents, we probably would like to 
submit these patent applications before that date to better serve the company's interests. 

Please let us know your thoughts . 

Thank you very much. 
Lei 
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Margo Livesay 



From: 
Sent: 
To: 
Cc: 



Brian F. Russell [brussell@patentlawyers.com] 
Wednesday, November 22, 2000 1 1 :45 AM 
lei.yao 

dave.mcdysan; lee.thomas; Paul.roberts 
Re: Patent applications 



Subject: 



Gentlemen, 



Thank you for your assistance in preparing the patent applications. I have reviewed the 
comments you had and have finished incorporating them into the applications. 

To speed up preparatxon of the legal documents that will accompany the applications, I 
need updated addresses for each of you (the ones listed in the disclosure seem to be out 
of date) . 

Thank you for your help. 
Best regards, 
Brian. F. Russell 

Feistnan, Bradley, Vaden, Gunter & Dillon, LLP 

Suite 3 50, Lakewood on the. Park 

7600B N. Capital of Texas Hwy . 

Austin, TX 78731 

512.343.6116 (voice) 

512.343.6002 (fax) 

brxissellOpatentlawyers . com 

www . patent lawyers . com 



Patent Docket No.: RIC00043 



DECLARATION AND POWER OF ATTORNEY 
FOR UTILITY PATENT APPLICATION 



As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below, next to my name, 

I believe I am the original, first and sole inventor (if only one name is listed below) or an original first and 
joint inventor (if plural names are listed below) of the subject matter which is claimed and for which a 
patent is sought on the invention entitled: 



the specification of which 

is attached hereto 

X was filed on November 28, 2000 

as Application Serial No. 09/723,501 
and was amended on 



I hereby state that I have reviewed and understand the contents of the above-identified specification, 
including the claims, as amended by any amendment referred to above. I do not know and do not believe 
that the same was ever known or used in the United States of America before my invention thereof, or 
patented or described in any printed publication in any country before my invention thereof of more than 
one year prior to this application, and said invention has not been patented or made the subject of an 
inventor's certificate issued before the date of this application in any country foreign to the United States of 
America on an application filed by me or my legal representatives or assigns more than twelve months 
prior to this application. 



I acknowledge the duty to disclose information which is material to the patentability of this application in 
accordance with Title 37, Code of Federal Regulations, Sectionl. 56(a). 



I hereby claim foreign priority benefits under Title 35, United States Code §1 19 (a)-(d) or §365(b) of any 
foreign application(s) for patent or inventor's certificate, or §365(a) of any PCT international application 
which designated at least one country other than the United States of America, listed below and have also 
identified below, by checking the box, any foreign application for patent or inventor's certificate, or of any 
PCT international application having a filing date before that of the application on which priority is 



External Processor For A Distributed Network Access System 



claimed. 



Prior Foreign Application(s) 



Priority Claimed 
yes n 



no 



(number) 



(country) 



(date filed) 



EXHIBIT N 



Patent Docket No.: RIC00043 



I hereby claim the benefit under Title 35, United States Code§l 19(e) of any United States provisional 
application(s) listed below. 



(Application Number(s)) (Filing Date mm/dd/yy) 

I hereby claim the benefit under Title 35, United States Code, Section 120 of any United States 
application(s) or Section365(c) of any PCT international application designating the United States of 
America, listed below, and insofar as the subject matter of each of the claims of this application is not 
disclosed in the prior United States or PCT international application in the manner provided by the first 
paragraph of Title 35, United States Code, Section 1 12, 1 acknowledge the duty to disclose information 
which is material to patentability as defined in Title 37, Code of Federal regulations, Section 1.56 which 
became available between the filing date of the prior application and the national or PCT international 
filing date of this application. 



(Application Serial No.) (Filing date) (Status) 

I hereby appoint Steven McCann, Reg. No. 34,958; Paul A. Roberts, Reg. No. 40,289; Michael B. 
Chernoff, Reg. No. 42.408; Suresh Koshy, Reg. No. 42,761; Brian C. Oakes, Reg. No. 41, 467;; Andrew J. 
Dillon, Reg. No. 29,634; Brian F. Russell, Reg. No. 40,796; Matthew W. Baca, Reg. No. 42,277; Antony P. 
Ng, Reg. No. 43,427; Richard McCain, Reg. No. 43,785; and Michael E. Noe, Jr., Reg. No. 44,975 my 
attorneys and Frank A. McKiel, Reg. No. 43,792 my patent agent with full power of substitution and 
revocation, to prosecute this application and to transact all business in the Patent and Trademark Office 
connected herewith. 

Send future correspondence to: Direct Telephone Calls To: 

Technology Law Department (202) 736-6604 

MCI WORLDCOM, Inc. 
1133 19* STREET NW 
WASHINGTON, D.C. 20036 

I hereby declare that all statements made herein of my knowledge are true and that all statements were 
made with the knowledge that willful false statements and the like so made are punishable by fine or 
imprisonment, or both, under Section 1001 of Title 18 of the United States Code and that such willful false 
statements may jeopardize the validity of the application or any patent issued thereon. 

Full name of Sole or First Inventor: Dave McDvsan 

P.O./Residence Address: 2159 Astoria Circle, #104, Herndon, VA 201 70 

Citizenship: . United S tates o f A merica 

Signature: (KJ^VP W{ A^— Date: 1^ 1 2.Q) 1 



Full name of Additional Joint Inventor, if any: Howard Lee Thomas 

P.O./Residence Address: 325 Woodmar Court, Ballwin, MO 6331 1 

Citizenship: United States of America 

Signature: Date: 
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Full name of Additional Joint Inventor, if any: Lei Yao 

P.O./Residence Address: 2000 S. Eads Street, #517, Arlington, VA 22202 

Citizenship: China 

Signature: ^tgyo Date: 01/ f^/^joO ( 
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Patent Docket No.: RIC00043 



DECLARATION AND POWER OF ATTORNEY 
FOR UTILITY PATENT APPLICATION 



As a below named inventor, I hereby declare that: 

My residence, post office address and citizenship are as stated below, next to my name, 

I believe I am the original, first and sole inventor (if only one name is listed below) or an original first and 
joint inventor (if plural names are listed below) of the subject matter which is claimed and for which a 
patent is sought on the invention entitled: 

External Processor For A Distributed Network Access System 

the specification of which 

is attached hereto 

X_ was filed on November 28, 2000 

as Application Serial No. 09/723,501 
and was amended on 



I hereby state that I have reviewed and understand the contents of the above-identified specification, 
including the claims, as amended by any amendment referred to above. I do not know and do not believe 
that the same was ever known or used in the United States of America before my invention thereof, or 
patented or described in any printed publication in any country before my invention thereof of more than 
one year prior to this application, and said invention has not been patented or made the subject of an 
inventor's certificate issued before the date of this application in any country foreign to the United States of 
America on an application filed by me or my legal representatives or assigns more than twelve months 
prior to this application. 



I acknowledge the duty to disclose information which is material to the patentability of this application in 
accordance with Title 37, Code of Federal Regulations, Sectionl. 56(a). 



I hereby claim foreign priority benefits under Title 35, United States Code § 1 19 (a)-(d) or §365(b) of any 
foreign application(s) for patent or inventor's certificate, or §365(a) of any PCT international application 
which designated at least one country other than the United States of America, listed below and have also 
identified below, by checking the box, any foreign application for patent or inventor's certificate, or of any 
PCT international application having a filing date before that of the application on which priority is 
claimed. 

Prior Foreign Application(s) Priority Claimed 

yes no 

(number) (country) (date filed) 
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I hereby claim the benefit under Title 35, United States Code§119(e) of any United States provisional 
application(s) listed below. 



(Application Number(s)) (Filing Date mm/dd/yy) 

I hereby claim the benefit under Title 35, United States Code, Section 120 of any United States 
application(s) or Section365(c) of any PCT international application designating the United States of 
America, listed below, and insofar as the subject matter of each of the claims of this application is not 
disclosed in the prior United States or PCT international application in the manner provided by the first 
paragraph of Title 35, United States Code, Section 1 12, 1 acknowledge the duty to disclose information 
which is material to patentability as defined in Title 37, Code of Federal regulations, Section 1.56 which 
became available between the filing date of the prior application and the national or PCT international 
filing date of this application. 



(Application Serial No.) (Filing date) (Status) 

I hereby appoint Steven McCann, Reg. No. 34,958; Paul A. Roberts, Reg. No. 40,289; Michael B. 
Chernoff, Reg. No. 42.408; Suresh Koshy, Reg. No. 42,761; Brian C. Oakes, Reg. No. 41, 467;; Andrew J. 
Dillon, Reg. No. 29,634; Brian F. Russell, Reg. No. 40,796; Matthew W. Baca, Reg. No. 42,277; Antony P. 
Ng, Reg. No. 43,427; Richard McCain, Reg. No. 43,785; and Michael E. Noe, Jr., Reg. No. 44,975 my 
attorneys and Frank A. McKiel, Reg. No. 43,792 my patent agent with full power of substitution and 
revocation, to prosecute this application and to transact all business in the Patent and Trademark Office 
connected herewith. 

Send future correspondence to: Direct Telephone Calls To: 

Technology Law Department (202) 736-6604 

MCI WORLDCOM, Inc. 
1133 19 th STREET NW 
WASHINGTON, D.C. 20036 

I hereby declare that all statements made herein of my knowledge are true and that all statements were 
rnade with the knowk d"e «nt ™<M\\ C?.l^ ^t?.t?>~ws ar^ tb<? «V» sre w^IoKau v, v or 

imprisonment, or both, under Section 1001 of Title 18 of the United States Code and that such willful false 
statements may jeopardize the validity of the application or any patent issued thereon. 

Full name of Sole or First Inventor: Dave McDysan 

P.O./Residence Address: 2159 Astoria Circle, #104, Herndon, VA 201 70 

Citizenship: United States of America 

Signature: Date: 



Full name of Additional Joint Inventor, if any: Howard Lee Thomas b$oit 



P.O./Residence Address: 325 Woodmar Court, Ballwin, MO-63~3TT r ',y^/ ( , ( . 

Citizenship : United States ofAmericar , ' ' c ^' 6 c 

Signature: , ';' ) . /^w,,-,, • Date: 
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Full name of Additional Joint Inventor, if any: Lei Yao 

P.O./Residence Address: 2000 S. Eads Street, #517, Arlington, VA 22202 

Citizenship: China 

Signature: Date: 
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